​
Merchant playbooks

These are the shortest operational runbooks for common Hilt issues. They assume the merchant already has one live product and wants the next action quickly.

​
1. Go live with one clear product

The safest first launch is still:
  1. create one real product
  2. make the price and delivery path obvious
  3. validate checkout and access before wider traffic
  4. verify payment, membership, receipt, and support state after the first real buyer or optional low-value live check
Do not create many offers before one full trail is proven.

​
2. Payment confirmed but access did not land

When a buyer says “I paid, but I do not have access”:
  1. find the membership or payment first
  2. open provider diagnostics for Telegram or Discord when available
  3. retry delivery if the issue looks transient
  4. keep the linked support ticket attached if the case still needs a human trail
That keeps recovery tied to the same membership history instead of scattered messages.

​
3. A recurring buyer needs the next period

Recurring products use the native subscription collection path when the workspace is approved for native automatic renewals. When a recurring buyer needs the next step:
  1. open the member record
  2. inspect the membership and subscription detail
  3. confirm the cancellation, collection, or post-period access state for the member
  4. check native subscription collection, cancellation, or post-period cleanup state if the product uses native automatic renewals
  5. use the support trail only when the recurring path is unclear or broken

​
4. A buyer needs proof of payment

When proof is the main issue:
  1. open the receipt
  2. use the public proof page when a browser view is enough
  3. send the proof link or PDF directly when the buyer needs a clean artifact
That is much better than screenshots because the proof stays verifiable and consistent.

​
5. Your integration or webhook path looks broken

When an external system looks out of sync:
  1. check recent webhook deliveries in the dashboard
  2. re-send the webhook when the downstream endpoint is fixed
  3. use the event timeline to see what Hilt actually emitted for the payment or membership
  4. if you are still building, test the same flow in the sandbox before touching live traffic again

​
6. Support reply checklist

When a buyer writes in, the clean sequence is:
  1. find the payment, membership, or receipt
  2. decide whether the issue is delivery, renewal timing, or proof
  3. run the built-in action that matches that problem
  4. reply with the next concrete step, not a vague status message
That is the habit that makes Hilt support feel calm and professional.

​
Common questions

​
What are Hilt merchant playbooks for?

They are short operating playbooks for common launch, access, renewal, proof, webhook, and support situations after checkout.

​
Which playbook should I use first?

Use the first-launch playbook until one product, one payment, one receipt, and one access trail are proven end to end.

​
What should I do when access does not land?

Find the payment or membership, inspect provider diagnostics when available, retry delivery if the problem is transient, and keep the linked support ticket attached if the case needs a human trail.