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:- create one real product
- make the price and delivery path obvious
- run one tiny live payment
- verify payment, membership, receipt, and support state afterwards
2. Payment confirmed but access did not land
When a buyer says “I paid, but I do not have access”:- find the membership or payment first
- open provider diagnostics for Telegram or Discord when available
- retry delivery if the issue looks transient
- keep the linked support ticket attached if the case still needs a human trail
3. A recurring buyer needs the next period
Hilt is manual-renewal-first right now. When a recurring buyer needs the next step:- open the member record
- load the reactivation detail
- send the renewal or reactivation link that Hilt is already using for that member
- 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:- open the receipt
- use the public proof page when a browser view is enough
- send the proof link or PDF directly when the buyer needs a clean artifact
5. Your integration or webhook path looks broken
When an external system looks out of sync:- check recent webhook deliveries in the dashboard
- re-send the webhook when the downstream endpoint is fixed
- use the event timeline to see what Hilt actually emitted for the payment or membership
- 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:- find the payment, membership, or receipt
- decide whether the issue is delivery, renewal timing, or proof
- run the built-in action that matches that problem
- reply with the next concrete step, not a vague status message