Native subscriptions

Native subscriptions are Hilt’s Solana USDC recurring access flow. Use them when a buyer should approve a subscription once from their wallet and keep access active through successful collections. Hilt connects the subscription to the operating records a merchant or developer needs:

the buyer approval
the recurring product
the collection event
the receipt
the member or entitlement period
the paid-through date
the cancellation state
webhook delivery
support context
analytics and audit history

When to use native subscriptions

Use native subscriptions for recurring access, such as:

paid communities
private Telegram or Discord access
memberships
paid APIs
AI tools and bots
datasets and research products
courses and cohorts
software access
WooCommerce products that represent recurring access

Use a one-off payment instead when the buyer should pay once for a fixed unlock, file, download, service, deposit, or non-renewing access period.

What the buyer sees

The buyer approves the subscription setup from their wallet. After the first payment succeeds, Hilt records the receipt and activates the member or entitlement period. Future successful collections extend the paid-through date. This is not a card-style hidden charge flow. The buyer approval, access period, cancellation state, and payment evidence stay visible through Hilt.

What Hilt records

For each native subscription flow, Hilt keeps the business state connected:

Record	Why it matters
Product or template	Defines the recurring offer, price, interval, and access destination
Buyer approval	Shows that the buyer approved the Solana USDC subscription setup
Collection event	Shows whether the next period was collected successfully
Receipt	Gives the buyer and merchant proof of payment
Member or entitlement	Defines whether the buyer currently has access
Paid-through date	Shows the access period created by successful payment
Cancellation state	Shows whether future collection should stop
Webhook trail	Keeps the merchant backend, CRM, community, or app in sync
Support context	Lets support answer renewal and access questions from the real record
Analytics	Shows recurring revenue and access pressure without rebuilding it from wallet history

Workspace setup

In Hilt Pay Workspace, create or edit a template and choose the recurring option. The recurring setup should make these fields clear:

buyer-facing title
buyer-facing description
price
billing interval
access destination
payout wallet
receipt wording
cancellation behavior

For recurring products, use Native automatic renewal. That tells Hilt the buyer should approve a Solana USDC subscription and that successful collections should extend access. Before sending real buyer traffic, confirm:

the product copy is clear
the payout wallet is correct
the access destination is correct
the buyer success state is clear
the webhook receiver is ready if your product depends on webhook sync
the first subscription flow has been validated with a low-risk offer or sandbox path

Hilt Pay API setup

For API products, create a recurring access product with:

billing_model: "recurring"
renewal_mode: "solana_native_subscription"
billing_interval_days
cancel_at_period_end: true
default_rail: "solana_usdc"

Example:

curl -X POST https://api.hilt.so/v1/access/products \
  -H "Content-Type: application/json" \
  -H "X-Hilt-Key: $HILT_API_KEY" \
  -H "Idempotency-Key: product-pro-api-monthly-001" \
  -d '{
    "access_app_id": "ACCESS_APP_ID",
    "external_product_id": "pro-api-monthly",
    "title": "Pro API monthly access",
    "amount_minor_units": 79000000,
    "default_rail": "solana_usdc",
    "billing_model": "recurring",
    "renewal_mode": "solana_native_subscription",
    "billing_interval_days": 30,
    "cancel_at_period_end": true,
    "status": "active",
    "live_mode_confirmed": true
  }'

Then create a payment session for that product:

curl -X POST https://api.hilt.so/v1/access/payment-sessions \
  -H "Content-Type: application/json" \
  -H "X-Hilt-Key: $HILT_API_KEY" \
  -H "Idempotency-Key: session-cust-123-pro-api-monthly-001" \
  -d '{
    "external_product_id": "pro-api-monthly",
    "external_customer_id": "cust_123",
    "rail": "solana_usdc"
  }'

After the buyer completes the payment and subscription setup, keep checking access through Hilt:

curl -X POST https://api.hilt.so/v1/access/entitlements/check \
  -H "Content-Type: application/json" \
  -H "X-Hilt-Key: $HILT_API_KEY" \
  -d '{
    "external_product_id": "pro-api-monthly",
    "external_customer_id": "cust_123"
  }'

Serve the protected resource only when Hilt returns has_access: true.

Webhooks for recurring access

Subscribe your backend to the events that keep your own system aligned:

curl -X POST https://api.hilt.so/v1/access/webhooks \
  -H "Content-Type: application/json" \
  -H "X-Hilt-Key: $HILT_API_KEY" \
  -H "Idempotency-Key: webhook-recurring-access-001" \
  -d '{
    "label": "Recurring access sync",
    "url": "https://api.example.com/hilt/webhook",
    "subscribed_events": [
      "payment.confirmed",
      "receipt.created",
      "membership.activated",
      "membership.renewed",
      "membership.expired",
      "subscription.cancelled"
    ]
  }'

Use webhooks to update:

your app’s access state
a community member role
a CRM record
a support record
a reporting job
an email or notification workflow

Always verify webhook signatures and process events idempotently.

Cancellation

Cancellation is period-aware. When a buyer cancels:

future collection stops
the buyer can remain active until the paid-through date
Hilt records the cancellation state
your product should keep using Hilt entitlement checks for access decisions

API products can create and confirm a cancellation flow:

curl -X POST https://api.hilt.so/v1/access/native-subscriptions/AUTHORIZATION_ID/cancel-intent \
  -H "Content-Type: application/json" \
  -H "X-Hilt-Key: $HILT_API_KEY" \
  -d '{
    "reason": "buyer_requested",
    "cancel_at_period_end": true
  }'

After the signed cancellation is complete:

curl -X POST https://api.hilt.so/v1/access/native-subscriptions/AUTHORIZATION_ID/cancel-confirm \
  -H "Content-Type: application/json" \
  -H "X-Hilt-Key: $HILT_API_KEY" \
  -H "Idempotency-Key: native-cancel-AUTHORIZATION_ID-001" \
  -d '{
    "cancel_tx_signature": "SOLANA_CANCEL_TRANSACTION_SIGNATURE",
    "reason": "buyer_requested",
    "immediate_revoke": false,
    "verify_onchain": true
  }'

If immediate_revoke is false, keep access available until the current paid-through date.

Support workflow

When a recurring buyer asks for help, start from the member, entitlement, or receipt record. Check:

what product they bought
whether the subscription is active
the current paid-through date
the latest receipt
whether a cancellation is recorded
whether the webhook destination received the latest event
whether the access destination still matches the product promise

This keeps support tied to evidence instead of wallet screenshots or transaction-hash guesswork.

Common questions

Does Hilt custody subscription funds?

No. Buyers pay from their own wallet and merchants settle to their configured payout wallet. Hilt records the subscription, receipt, access period, webhook trail, support context, analytics, and audit history around the payment.

Does cancellation remove access immediately?

Not by default. Cancellation stops future collection. Access can remain active until the paid-through date, depending on the product and cancellation choice.

Can Hilt Pay API products use native subscriptions?

Yes. Hilt Pay API can create recurring products, start payment sessions, check entitlements, receive webhooks, and expose subscription state to the merchant’s own product.

Should I use native subscriptions for every product?

No. Use native subscriptions when access should renew. Use one-off payments when the buyer should pay once for a fixed unlock or fixed access period.

What should my app rely on for access?

Use Hilt entitlement checks. Do not grant access from a wallet claim, client-side receipt, or raw transaction hash alone.

Start here

Selling with Hilt

Running your workspace

Native subscriptions

Native subscriptions

When to use native subscriptions

What the buyer sees

What Hilt records

Workspace setup

Hilt Pay API setup

Webhooks for recurring access

Cancellation

Support workflow

Common questions

Does Hilt custody subscription funds?

Does cancellation remove access immediately?

Can Hilt Pay API products use native subscriptions?

Should I use native subscriptions for every product?

What should my app rely on for access?

​Native subscriptions

​When to use native subscriptions

​What the buyer sees

​What Hilt records

​Workspace setup

​Hilt Pay API setup

​Webhooks for recurring access

​Cancellation

​Support workflow

​Common questions

​Does Hilt custody subscription funds?

​Does cancellation remove access immediately?

​Can Hilt Pay API products use native subscriptions?

​Should I use native subscriptions for every product?

​What should my app rely on for access?

Native subscriptions

When to use native subscriptions

What the buyer sees

What Hilt records

Workspace setup

Hilt Pay API setup

Webhooks for recurring access

Cancellation

Support workflow

Common questions

Does Hilt custody subscription funds?

Does cancellation remove access immediately?

Can Hilt Pay API products use native subscriptions?

Should I use native subscriptions for every product?

What should my app rely on for access?