27 August 2026Live
Agents can now pay verified PayMe handles through public MPP and buy normalized Solana transaction evidence through a working 0.05 USDC x402 V2 resource.
- The public PayMe action lets an agent pay an active verified X handle in native SOL or Solana USDC without a payer account, OAuth grant, or Hilt API key.
- Its MPP HTTP 402 challenge pins the network, recipient, asset, amount, fee, expiry, and payment identity before the agent signs under its wallet policy.
- A successful retry returns a machine-readable Hilt receipt tied to the finalized Solana transaction.
- Hilt's Transaction Evidence endpoint is a separate paid resource: one 0.05 USDC x402 V2 payment returns normalized finalized Solana transaction facts.
- The evidence flow completes settlement, receipt creation, entitlement, atomic usage consumption, and protected-result delivery without a buyer account or API key.
- PayMe MPP pays a verified recipient and issues a receipt. Hilt Pay API x402 sells protected access or output. The two contracts are intentionally distinct.
26 August 2026Live
Hilt SDK 1.4.0 packages the complete metered-request loop for Fetch-compatible and Python services.
- The TypeScript protectEndpoint wrapper atomically consumes usage before serving billable work.
- When usage is missing, the wrapper returns Hilt's HTTP 402 payment requirement, settles the buyer's Solana USDC payment signature, and retries consumption.
- Python services can use protect_request as the same framework-neutral decision boundary.
- Settlement, receipt, entitlement, and usage remain separate states, with retry-safe handling that does not ask a buyer to pay twice.
- The buyer agent pays through x402 V2 while the protected API keeps its request body, result, and Hilt credential on the server.
24 August 2026Live
Developers can launch Hilt Pay API products without a monthly subscription and choose Solana USDC or native SOL settlement.
- Sandbox remains free and does not process live money.
- Live costs $0 per month plus 1% on each successful settlement, charged in the settlement asset.
- Native SOL is available through hosted payment sessions with the same verified receipt, entitlement, webhook, support, and audit lifecycle.
- TypeScript SDK 1.3.0 and Python SDK 1.3.0 include native SOL hosted-session guidance and updated settlement fields.
- Hilt x402 V2 continues to settle in Solana USDC; native SOL is not presented as an x402 asset.
- Native Solana subscriptions remain Solana USDC-only, and separate API products are required for USDC and SOL settlement.
20 August 2026Live
PayMe recipients can now protect future receiving-wallet changes with current-wallet approval, a standard Authenticator app, and single-use recovery codes.
- Initial Authenticator enrollment requires a one-time message signature from the wallet that currently receives PayMe payments.
- After enrollment, changing the receiving wallet requires a current Authenticator code or unused recovery code plus a signature from the new wallet.
- The old wallet does not need to sign a later protected change, providing a recovery path when it becomes inaccessible.
- If the current wallet is inaccessible and Wallet Security was not enabled beforehand, self-service replacement is blocked.
- Wallet Security affects future PayMe payments only. It does not move completed payments, send a setup transaction, or give Hilt wallet-signing authority.
8 August 2026Live
The Hilt PayMe custom connector now understands natural send-payment instructions, tracks outgoing and incoming activity, and creates payment links that users share themselves.
- A user can ask a compatible AI client to send SOL or Solana USDC to an OAuth-verified Hilt PayMe handle without using implementation terms such as prepare payment.
- Every outgoing payment receives a durable Hilt payment ID and exposes awaiting-wallet, authorized, confirmed, expired, cancelled, or known failed state.
- The connector reports the recipient, exact amount, flat 2% fee preview, wallet approval URL, and Solana transaction signature when confirmed.
- Payment links are self-shared. Hilt does not automatically contact, mention, message, or post to a named payer.
- Hilt remains zero-custody: the payer reviews and approves every outgoing payment with the wallet they choose. The payer does not need a PayMe account.
22 July 2026Live
Agents and developers can now discover Hilt through Agent Switchboard, Smithery, Agentverse, the Official MCP Registry, and Hilt's standard A2A and MCP endpoints.
- Agent Switchboard has accepted Hilt Pay Agent Gateway and lists its A2A, MCP, and API access paths for agent builders.
- Smithery publishes the live remote gateway as paul-rboo/hilt-pay-agent-commerce and successfully discovers all 10 public Hilt tools without requiring client configuration.
- The Official MCP Registry publishes so.hilt/agent-commerce version 1.1.0, while Agentverse provides an additional optional A2A discovery path.
- The canonical Hilt-hosted MCP gateway, A2A agent card, and A2A JSON-RPC endpoint remain the source of truth. Public discovery requires no authentication; protected Hilt Pay API operations use scoped credentials.
- These services help agents discover and inspect Hilt. They are not payment rails: Hilt Pay API settlement is handled separately through Solana USDC or native SOL, while Hilt x402 V2 remains Solana USDC.
20 July 2026Live
Hilt Pay API now provides a complete paid-request loop for agents: x402 V2 payment requirements, direct Solana USDC settlement, receipts, entitlements, webhooks, and atomic usage consumption.
- Protected resources can return a machine-readable HTTP 402 requirement, settle the signed payment through Hilt, and consume a metered entitlement unit before serving work.
- Hilt's hilt-exact payment terms describe one Solana USDC transaction with the required merchant and Hilt fee transfers, keeping payment allocation atomic and zero-custody.
- Settlement and usage calls are idempotent. If a finalized transaction needs to be reconciled after an interrupted request, the buyer is not asked to pay again.
- TypeScript SDK @hiltpay/sdk@1.2.0 and Python SDK hilt-sdk==1.2.0 add x402 V2 helpers, typed settlement methods, and atomic entitlement consumption.
- The public reference implementation now uses current Solana Kit transaction and token clients with a committed lockfile and repeatable CI validation.
- Hilt Pay API supports live Solana USDC and native SOL settlement. Hilt x402 V2 remains Solana USDC. x402 is the HTTP 402 protected-resource protocol shape, not a chain, token, wallet, or settlement rail.
4 June 2026Live
Hilt's public TypeScript SDK, Python SDK, Postman collection, Postman environment, examples, and Hilt-hosted developer downloads now reflect the live Hilt Pay API and native subscription surface.
- The TypeScript SDK is published as @hiltpay/sdk@1.1.0 and the Python SDK is published as hilt-sdk==1.1.0, with matching public GitHub sources and release assets.
- Both SDKs now include structured HiltError and HiltApiError models with error codes, request ids, retryability, docs URLs, and safe response details.
- Both SDKs add typed webhook signature verification and router helpers for signed Hilt events.
- Hilt Pay API write helpers now enforce idempotency keys locally and expose sandbox payment-session helpers for safer integration tests.
- Recurring-access examples now show product creation, subscription checkout, entitlement checks, renewal webhooks, and period-aware cancellation for Solana USDC native subscriptions.
- The docs clearly separate current native subscription helpers from future list, pause, resume, customer-session, and sandbox time-travel backend contracts.
4 June 2026Live
Hilt merchants and Hilt Pay API developers can now run automatic recurring billing on Solana USDC. Buyers approve a subscription once, and Hilt handles every subsequent collection, receipt, entitlement period, webhook event, and audit record automatically.
- One-off payments and native automatic subscriptions are now separate product modes with distinct product creation, checkout, and entitlement flows.
- Every successful collection produces the same operating record as the initial payment: payment confirmation, receipt, membership period extension, webhook event, support context, and audit history.
- Cancellation is period-aware: future collection stops, access remains valid through the paid-through date, and Hilt records the full cancellation state and timeline.
- Hilt Pay API now supports recurring products with billing_model: "recurring" and renewal_mode: "solana_native_subscription" so developers can ship subscription-gated APIs, AI tools, and access products with automatic renewal from code.
- The merchant workspace, native subscription docs, and API docs are updated to reflect the live product.
3 June 2026Live
Hilt's recurring-access model now centers on buyer-approved Solana USDC subscriptions, while keeping collection, receipts, memberships, webhooks, support context, and audit history inside the Hilt operating layer.
- Merchant templates now separate one-off payments and native automatic renewals.
- The native path keeps the buyer approval model explicit: the buyer signs once to approve a Solana USDC subscription, then Hilt records every later collection as normal payment-to-access evidence.
- Each successful collection becomes the same operating record merchants expect: payment, receipt, membership period, webhook event, support context, analytics signal, and audit history.
- Cancellation is period-aware: future collection stops immediately, while access can remain available through the paid-through date before post-period revoke or close handling.
- Developer docs now describe how native subscription setup, collection, cancellation, webhooks, and support evidence fit into Hilt Pay API and the merchant workspace.
1 June 2026Live
The public site, docs, and discovery surfaces now describe Hilt as payment-to-access infrastructure for agents, APIs and stablecoin commerce rather than a checkout tool.
- Hilt Pay Workspace and Hilt Pay API are now named and separated so merchants, developers, and agents can choose the right product surface.
- The operating layer is now the primary product description: receipts, entitlements, webhooks, audit trail, renewal state, support context, analytics, and payment proof.
- Checkout remains part of the product, but public copy now explains the complete payment-to-access workflow that happens after a buyer pays.
- Agent-readable surfaces now point developers and coding agents toward the same live docs, OpenAPI, Postman assets, SDKs, and Hilt Pay API setup path.
31 May 2026Live
Hilt Pay API now has a clearer public developer path for AI tools, APIs, bots, datasets, paid software, and private products that need stablecoin-paid access.
- The developer page now leads with Hilt Pay API, Agent Bootstrap, setup intents, x402 protected-resource protocol flows, Solana USDC settlement, SDKs, Postman, OpenAPI, and GitHub assets.
- The public site now has a dedicated x402 page and an agent setup page so humans, answer engines, and coding agents can understand the protocol boundary before integrating.
- Pricing now separates Hilt Pay Workspace from Hilt Pay API, with API tiers for Sandbox, Starter, Growth, Scale, and Enterprise plus an API-specific fee estimator up to $1m/month.
- The docs now treat Hilt Pay API as the agent/developer product surface, with explicit boundaries: x402 is a protocol, Solana USDC is the launch settlement rail, and additional settlement options will be announced when available.
- The LLM files now give answer engines the Workspace/API split, exact API pricing, recommended routes, and do-not-claim rules.
31 May 2026Live
The Hilt Pay for WooCommerce plugin now has an approved WordPress.org listing, giving WooCommerce merchants the standard plugin directory install path.
- The approved listing is live at wordpress.org/plugins/hilt-pay-for-woocommerce with the Hilt Pay slug and plugin assets.
- The WooCommerce page now points merchants directly to the WordPress.org listing while keeping the direct ZIP as a fallback.
- Docs have been updated so merchants install from WordPress.org first, then configure API key, webhook signing secret, product mapping, and one low-value live test.
21 May 2026Live
Hilt's merchant workspace now gives operators a clearer read on revenue, funnel movement, receipts, support, notifications, and Hilt subscription billing from one place.
- Merchant Analytics now supports clearer revenue-by-day views, date ranges, product lenses, checkout-funnel reporting, and day-level summaries instead of forcing merchants to interpret tiny hover-only charts.
- Receipts, CSV/PDF exports, tax/export records, and buy notifications are now shaped around Starter-and-above operating workflows, with public receipt proof keeping customer email details private.
- Support now sends merchant and user email updates around ticket creation and replies, while ticket context can stay linked to payment, receipt, member, or checkout details.
- Billing now exposes the Stripe customer portal more plainly so merchants can manage payment methods, invoices, and cancellation with the same transparency Hilt expects from buyer-facing flows.
20 May 2026Live
New merchants can now work through a guided setup path that connects wallet settings, checkout details, first-product creation, and channel-specific launch instructions.
- The Get Started wizard covers link-only, embed, WooCommerce, Telegram, Discord, redirect, download, and custom handoff paths without changing the underlying checkout rails.
- The wizard saves safe merchant defaults, creates the first checkout through the existing product API, and keeps existing Telegram, Discord, and checkout settings intact.
- Discord launches now surface the Hilt Connect invite path directly in the setup flow so merchants understand the bot requirement before relying on role automation.
- The dashboard keeps a launch checklist visible until the first setup steps are complete, making the first live product less dependent on guesswork.
19 May 2026Live
WooCommerce merchants gained the first dedicated Hilt path for routing eligible orders into hosted USDC checkout before the later WordPress.org approval.
- The new WooCommerce page explains the order handoff, hosted Hilt checkout, signed webhook confirmation, buyer return path, and merchant-owned payout model.
- The initial self-hosted plugin ZIP gave early merchants a test path before the later WordPress.org listing approval.
- The WooCommerce page made listing status explicit for early merchants while the plugin review was still underway.
- WooCommerce now appears in the public integration story, pricing comparison, developer page, and footer-level navigation where relevant.
17 May 2026Live
You can now add a Hilt checkout button to any page outside of Hilt, including Ghost posts, Carrd sites, Framer pages, Webflow, Kajabi, Beehiiv, or plain HTML.
- Copy the embed snippet from your template dashboard, paste it into your page, and the hosted Hilt checkout button renders automatically.
- For platforms that restrict custom scripts, the direct checkout link works as a fallback.
15 May 2026Live
Hilt checkout now uses one supported Solana wallet connection path across desktop and mobile, so merchants are no longer limited to a Phantom-only buyer story.
- Hosted checkout now opens a unified wallet flow for supported Solana wallets instead of presenting Phantom as the only direct on-chain route.
- That now includes the main wallet choices merchants will expect buyers to reach for, including Phantom, Solflare, Jupiter, Trust, and OKX.
- Desktop and mobile now follow the same wallet connection model, which reduces the old split between browser extension checkout and Phantom-specific mobile handoff logic.
- The public checkout surface now speaks in generic wallet language while keeping the same Hilt-owned payment, receipt, membership, and support flow around the transaction itself.
6 May 2026Live
Hilt's TypeScript SDK, Python SDK, Postman assets, and public developer assets now live in the open where technical teams expect to find them: npm, PyPI, GitHub, and the docs.
- The official JavaScript SDK now installs from npm as @hiltpay/sdk and the official Python SDK now installs from PyPI as hilt-sdk.
- The SDK sources now live in dedicated public GitHub repos instead of only being distributed as Hilt-hosted bundles.
- Approved OpenAPI snapshots, Postman imports, and example webhook payloads now also live in a public developer-assets repo alongside the docs.
5 May 2026Live
Hilt now exposes webhook, recurring-ops, proof, and sandbox workflows consistently across the CLI, public runbooks, developer docs, and API.
- The public CLI now reaches the newer webhook, testing, recurring-recovery, delivery-diagnostics, and proof-sharing surfaces instead of stopping at basic product and receipt reads.
- Public merchant and developer playbooks now turn webhook launch, delivery rescue, recurring recovery, and proof handling into explicit runbooks rather than scattered checklist fragments.
- Testing is sandbox-first: Hilt provides sandbox API testing, setup-readiness checks, and optional low-value live settlement checks before real traffic.
5 May 2026Live
Hilt now publishes first-party TypeScript and Python SDK download artifacts plus a real Postman collection and environment.
- The public developer surface now includes a downloadable TypeScript SDK tarball, Python wheel, Python source distribution, and first-party Postman import files from hilt.so.
- Developer docs now point to an official SDKs and Postman page instead of telling teams to generate their own client before they can get moving.
- The new assets cover the main Hilt API areas: products, hosted checkout, payments, memberships, receipts, support, and webhooks.
5 May 2026Live
Hilt now gives merchant teams a clearer operating read on checkout funnel movement, take-home by product, subscription pressure, delivery failure, and support load from one reporting layer.
- Merchant Analytics now shows hosted checkout opens, payment session starts, confirmed payments, and a daily open → connect → confirmed funnel instead of leaving teams to piece that story together from raw receipts.
- Product reporting now combines net take-home, fees, subscription pressure, delivery-failed rate, and support load so merchants can see what is actually causing drag on a live template.
- Admin analytics now includes a merchant-operations layer with workspace attention signals, product heat, and cross-platform renewal, delivery, and support pressure alongside launch traffic.
- Hosted checkout opens are now recorded as a first-class signal so the funnel reflects real checkout demand rather than guessed marketing traffic.
5 May 2026Live
Hilt now gives merchants and support teams a stronger operating layer around webhook delivery, recurring access flows, Telegram or Discord access recovery, provider diagnostics, and public receipt proof.
- Webhook endpoints can now send signed test events, inspect payment or membership event timelines, and work from a clearer delivery-log flow before re-sending a webhook.
- Native recurring flows now expose expiring-soon cohorts, collection timing, cancellation state, recent renewal events, and product-level reporting across merchant and admin views.
- Telegram and Discord memberships now surface provider diagnostics plus support-linked recovery actions so merchant teams can inspect live provider state before retrying or escalating.
- Receipt proof now includes a richer public proof page, PDF generation, invoice metadata, receipt search filters, and direct send-proof actions from support and operations.
4 May 2026Live
Hilt now carries a cleaner recurring-access model across checkout, members, support, admin operations, and the public plan story, with one-off payments and native automatic subscriptions described the same way everywhere.
- One-off payments and native recurring flows are now treated as separate commercial modes instead of one fuzzy recurring setup.
- Members, support, and admin operations now speak in the same recurring-access language as the merchant builder and public pricing pages.
- Recurring access keeps buyer approval explicit while Hilt records the payment, receipt, member state, support context, and audit trail.
4 May 2026Live
Merchants can now see recent webhook deliveries inside the Hilt dashboard and re-send stuck webhooks themselves when an endpoint has fallen behind.
- Dashboard Advanced now shows merchant-visible webhook endpoints and recent delivery logs from the live queue.
- Retry-scheduled and dead-letter deliveries can now be re-sent from the dashboard once the downstream consumer is ready again.
- Webhook docs and release notes now reflect merchant re-send as a real self-serve recovery path.
4 May 2026Live
Hilt pricing now spells out one-off payments and native automatic subscriptions more clearly, while the developer docs now present webhooks as a first-class integration surface instead of a polling footnote.
- Pricing plans and comparison cards now describe renewal execution in plain English without implying a live background-renew path.
- The Developers page, pricing calculator, and comparison copy now align around the same one-off and native recurring story.
- Webhook docs now lead with quickstart, event catalog, signatures, delivery behavior, idempotency, and migration from polling.
4 May 2026Live
Hilt templates now distinguish one-off payments from native recurring flows in the product model, builder language, and pricing story, so merchants are not guessing what renewal means.
- One-off payment and native recurring flows are now treated as separate modes instead of one implicit membership setup.
- The builder, pricing pages, and public docs now explain payment model and renewal model in the same plain-English way.
- Recurring operations now have a clearer manual-renew story instead of vague renewal wording.
4 May 2026Live
Failed membership delivery and failed expiry revoke paths now move through a queue-backed rescue system with retry scheduling, manual-review escalation, and a dedicated Delivery operations desk in admin.
- Failed Telegram and Discord access handoffs now enter a real rescue queue instead of sitting as one-off membership errors.
- Expiry revoke failures now retry on the same operational backbone, with manual review once automated rescue is exhausted.
- Admin now has a dedicated Delivery workspace with due jobs, recent attempts, merchant readiness gaps, and queue controls.
4 May 2026Live
Hilt now emits signed outbound events directly from payment, receipt, membership, and support state, with retry scheduling, dead-letter handling, and replay controls.
- Signed outbound events for payment confirmation, payment failure, receipt creation, membership lifecycle changes, failed delivery, and new support tickets.
- Dedicated delivery queue with retries, dead-letter handling, and replay controls in the Hilt admin workspace.
- Public developer docs updated so teams can rely on native Hilt webhooks first, while still using polling as a fallback where needed.
1 May 2026Live
Hilt launched publicly as a non-custodial Solana payments and access platform for memberships, gated communities, and digital products.
- The public site, merchant app, docs, pricing, and developer path all went live together under the same merchant-first story.
- The launch product was simple and honest from day one: one-off payments, direct merchant payouts, receipts, and support context.
- Status, trust, contact, and legal surfaces shipped with the public release so early merchants and developers had a credible operating layer around the checkout itself.
30 April 2026Live
Before launch, Hilt tightened the public site, docs, developer pages, and merchant trust surfaces so the outside story matched the real product more closely.
- Contact, trust, footer, and legal pages were brought into line with the live merchant experience and the real business details behind Hilt.
- The public developer surfaces were reshaped around the supported Hilt contract instead of older private planning wording and stale positioning.
- Docs reliability, support contact details, pricing language, and public navigation were cleaned up so launch traffic did not land on mixed or older product language.
