​

Templates

Templates are the merchant-facing way to build what the API and CLI call a product. They are the same commercial object. The dashboard simply uses the word merchants see every day.

​

What every template should answer

A strong template answers these questions immediately:

1. what is the buyer getting
2. what does the buyer pay
3. what happens after payment
4. where does the merchant receive the funds

If any of those answers feel vague, the template is not ready yet.

​

The builder sequence

The builder is easiest to use when you move through it in order:

1. Offer format Choose whether this is a Telegram membership flow, Discord access flow, gated redirect, digital product, download, or custom path.
2. Offer Set the buyer-facing title, description, and optional cover image.
3. Pricing and renewal Set whether the offer is one-off or recurring, then add interval and grace only when the access should renew.
4. Payout and access Confirm the payout wallet and the buyer destination after payment.

​

Choose the offer format first

Pick the format the buyer already understands before they even reach checkout:

• Telegram memberships
• Discord access
• redirects and gated links
• digital products and downloads
• custom merchant-handled delivery

The best templates feel familiar before the buyer reads the fine print.

​

Offer copy

The title and description should sell the offer clearly, not sound technical or abstract. Good:

• Telegram Inner Circle
• Monthly access to the members channel and weekly live calls

Weak:

• Tier 2 access control package
• Subscription workflow for premium cohort

Buyers should feel the value, not decode the merchant’s own shorthand.

​

Pricing and renewal

Inside the builder, merchants should expect to set:

• one-time access or native automatic subscriptions
• buyer price
• subscription interval when the access repeats
• grace period for native recurring access

The clean commercial split is:

• One-off payment for single unlocks and non-renewing access
• Native automatic renewals when the buyer should approve a Solana USDC subscription once and let Hilt collect future periods automatically

For the full recurring access flow, see Native subscriptions. The offer summary should always make the money obvious:

• buyer price
• Hilt fee
• estimated merchant take-home

​

Recurring operations after launch

If the template is recurring, the merchant should expect Hilt to keep the operational story readable after payment too. That now includes:

• expiring-soon cohorts
• collection timing
• grace windows
• renewal history
• period-aware cancellation and access state
• native subscription collection evidence when the workspace is approved for automatic collection

Native automatic renewals are the Solana USDC subscription path. In that model the buyer signs once to approve the subscription, and each successful collection still becomes a normal Hilt operating record: payment, receipt, membership period, webhook, support context, audit event, and analytics signal. Native cancellation is also period-aware. If a buyer cancels after paying for a period, future collection stops and access remains available through the paid-through date. Post-period revoke or close handling then cleans up the access state.

​

Payout and access

Every template should make these outcomes clear:

• where the money goes
• where the buyer goes after payment

That means the payout wallet and the success destination are part of the commercial promise, not just setup details. For Telegram and Discord specifically, also decide whether the workspace should rely on:

• saved static invite links
• provider-driven automation using the merchant’s connected bot settings

Hilt now gives merchants a delivery-readiness view and provider test actions in Settings so those assumptions can be checked before traffic arrives. Once payments are live, Hilt also gives merchants provider diagnostics and support-linked recovery actions from the Members and Support surfaces, so Telegram or Discord issues can be worked from the real member record instead of guesswork.

​

Branding and preview

Templates inherit workspace checkout branding, including:

• checkout brand name
• logo
• hero image
• accent color

Per-template details such as title, cover image, and success wording should make the offer feel specific rather than generic. Use the preview before publishing. It is the fastest way to catch:

• unclear copy
• awkward destination wording
• weak success-state language

​

Publish checklist

Before you publish a template:

• title is buyer-friendly
• description is specific
• payout wallet is correct
• success destination is correct
• pricing and renewal rules make sense
• preview looks trustworthy
• Telegram or Discord automation has been tested if the template depends on provider-driven delivery
• checkout and access have been validated

​

Good habits that keep templates sellable

• one clear promise per template
• one clear destination after payment
• one audience per offer
• one optional low-value live settlement check before wider traffic, when useful

Templates work best when buyers understand them at a glance and merchants can operate them from one clean ledger.

​

Common questions

​

What is a Hilt template?

A template is the merchant-facing offer in the dashboard. The API and CLI call the same object a product.

​

What should every template make clear?

Every template should make clear what the buyer gets, what they pay, what happens after payment, and where the merchant receives funds.

​

Should I launch several templates at once?

Start with one strong template, validate the checkout and access trail, and confirm the payment, access, receipt, and support views before publishing more offers.