​
Testing and going live

The safest Hilt launch path is not a fake environment. It is a real merchant workspace, one clear product, and one tiny live payment that proves the whole trail. Hilt does not currently provide a full fake checkout sandbox with separate settlement rails. Sandbox API keys are for marking lower-risk internal automation or pre-launch tooling inside a real merchant workspace. They help you separate that usage operationally, but they do not create a separate fake buyer checkout environment. For end-to-end launch validation, use one tiny live payment and verify the full post-payment trail afterwards.

​
The fastest reliable build order

  1. launch the product in the dashboard first
  2. create an API key for your backend or bot
  3. read the product through the API
  4. if needed, generate a signed handoff link for a known buyer
  5. run a tiny live payment
  6. verify payment, membership, receipt, and support state afterwards
That keeps your backend aligned with the same flow the merchant already understands.

​
What to test before real traffic

​
1. Product setup

Confirm that the product returned by GET /v1/products/{product_id} matches what the merchant expects:
  • title and description
  • price in minor units
  • payout wallet
  • delivery type and delivery value
  • renewal interval and grace period if access renews

​
2. Public checkout payload

Read the hosted payload with: 
curl https://api.hilt.so/v1/products/p/EXAMPLE_SLUG
Check that the buyer-facing values are correct:
  • branding
  • price
  • asset label
  • delivery path
  • membership requirements

​
3. Buyer handoff

If your backend already knows the buyer, test the full handoff path: 
curl -X POST https://api.hilt.so/v1/products/PRODUCT_ID/handoff-link \
  -H "X-Hilt-Key: hk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "identity_type": "TELEGRAM_USER_ID",
    "identity_value": "728255790",
    "identity_display": "@buyer",
    "expires_in_minutes": 30
  }'
Open the returned checkout_url and confirm the buyer arrives with the right identity already attached.

​
4. Tiny live payment

Use a very small real payment and keep the returned payment_id. That proves:
  • wallet flow
  • confirmation path
  • merchant fee calculation
  • payout routing
  • access delivery
  • merchant dashboard alignment

​
5. Async settlement check

After the buyer pays, read: 
curl https://api.hilt.so/v1/payments/PAYMENT_ID
Do not rely on the buyer UI alone. Treat the Hilt payment object as the durable answer.

​
6. Post-payment trail

Once the payment is final, check all three operating surfaces: 
curl "https://api.hilt.so/v1/memberships/lookup?tx_signature=TX_SIGNATURE" \
  -H "X-Hilt-Key: hk_live_..."

curl "https://api.hilt.so/v1/receipts?page=1&per_page=20" \
  -H "X-Hilt-Key: hk_live_..."

curl "https://api.hilt.so/v1/support/tickets?page=1&per_page=20" \
  -H "X-Hilt-Key: hk_live_..."
The goal is simple:
  • payment exists
  • membership exists if access should be active
  • receipt exists if proof should be visible
  • support can be opened if something needs human follow-up

​
The identifiers worth keeping

For a serious backend integration, persist these ids:
IdentifierWhy it matters
product_idStable merchant product record
slugBuyer-facing hosted checkout path
payment_idDurable join between checkout, payment, membership, and receipts
membership_idDurable access record once payment is confirmed
receipt_idDurable proof record
ticket_idDurable support conversation id

​
Good launch signals

You are in good shape when:
  • the buyer sees the right product
  • the payment confirms without a second signature
  • the merchant dashboard shows the same payment story
  • the membership record and receipt record line up with the payment
  • support can trace the same case from transaction to access state

​
Common launch mistakes

  • creating many products before proving one complete flow
  • treating payment confirmation as instantaneous everywhere
  • storing only the transaction signature and losing the payment_id
  • checking wallet activity but not checking memberships or receipts
  • shipping a handoff flow without testing identity prefill end to end