​

Merchant quickstart

This is the fastest safe route from a new Hilt account to one live Hilt flow. The goal is simple:

• launch one clear digital product, service, or membership
• validate checkout before wider traffic
• confirm the same story appears in Payments, Members, Receipts, and Support

You do not need to decide on API or CLI first. The dashboard is the right first launch path. Developers can automate the same live offer later from the API, SDKs, Postman, or CLI.

​

30-second first action

If you only do one thing right now, do this:

1. sign in to the dashboard
2. open Get Started
3. follow the wizard until your payout wallet, checkout details, and first template are saved

That alone gets you to a real merchant object you can inspect, share, and test. If you prefer to configure manually, set the payout wallet in Settings and then create one one-off payment link with a clear title and destination.

​

Watch the fastest launch path

If you prefer a screen-first walkthrough, start with these two clips before you read the rest of the guide.

​

1. Set up your Hilt workspace

This shows the merchant settings pass: workspace details, payout wallet, support URL, and checkout defaults. Watch on YouTube: Set up your Hilt workspace Expected outcome:

• payout wallet is set
• support URL is set
• buyer-facing checkout defaults are ready

​

2. Create your first template

This shows the builder pass: the offer type, buyer-facing copy, one-off vs recurring, price, and destination after payment. Watch on YouTube: Create your first template Expected outcome:

• one clear product is saved
• the payment model matches the commercial promise
• the hosted checkout is ready for buyers

​

What you should have by the end

• one published product
• one working checkout link
• one confirmed test payment
• one payment, receipt, and access record you trust

​

Use the launch wizard first

The Get Started wizard is the fastest dashboard path for a new merchant. It helps choose the right first setup route:

• link-only checkout
• embedded checkout
• WooCommerce
• Telegram
• Discord
• redirect or download
• custom handoff

For Discord flows, the wizard also points to the Hilt Connect invite path before the merchant depends on Discord role automation.

​

Before you start

Have these ready:

• the payout wallet you actually want to use
• the destination after payment, such as a Telegram area, Discord flow, private page, or download
• the support URL buyers should use if something goes wrong
• one clear one-line description of what the buyer gets

​

1. Set the workspace defaults first

Before you build a product, open the dashboard settings and set the buyer-facing defaults once:

• checkout brand name
• logo image
• hero image if you want one
• payout wallet
• support URL
• default redirect URL if your flow ends outside Hilt

Why this matters:

• every new product starts from the right baseline
• buyers see the same support and brand details across flows
• you avoid fixing the same merchant metadata repeatedly

Checkpoint:

• your payout wallet and support URL are already correct before you publish anything

​

2. Build one product, not five

For the first launch, pick one offer and make it obvious:

• one one-off digital product
• one paid service or private unlock
• one Telegram or Discord membership
• one gated redirect or download

The best first product is specific. A buyer should understand the promise in one glance.

​

3. Choose the payment model deliberately

Use the payment model that matches the commercial promise: Then set:

• buyer price
• payout wallet
• post-payment destination
• interval and grace window if the product repeats
• support URL
• buyer-facing description

Before you publish, check the offer summary in the builder:

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

Checkpoint:

• the product reads clearly
• the payment model matches what you intend to sell
• the payout wallet is the one you actually want money landing in

​

4. Publish the checkout and inspect it yourself

Before sending real traffic, open the hosted checkout yourself and check:

• the branding feels right
• the title and description make sense
• the destination after payment is correct
• the success state looks trustworthy
• the pricing and asset label are exactly what you expect

If anything feels ambiguous here, fix it before the first payment.

​

5. Validate before wider traffic

Use the dashboard trail before you post the link publicly. For most merchants, that means checking the hosted checkout page, confirming the buyer destination, and verifying that the product, payout wallet, member/access rule, and support path are correct. If you want one extra settlement proof, run an optional low-value live settlement check with your own wallet before real buyer traffic. Why this matters:

• it proves the buyer wallet path
• it proves the payout routing
• it proves receipt creation
• it proves the post-payment destination
• it proves Hilt records the payment, receipt, and access outcome correctly

Do not skip this step just because the product looks right.

​

6. Verify the records

After that payment, confirm the same story appears everywhere it should.

​

Payments

You should see:

• the transaction
• the product used
• the asset used
• the confirmed amount

​

Members

If the product creates access, you should see:

• the member record
• the current status
• the current period end date if access repeats

​

Receipts

You should see:

• the receipt
• the proof or verification surface
• the buyer-support trail you would use later if there is a dispute

​

Support

You should be confident that if something goes wrong later, support can attach to the same payment, membership, and receipt context instead of relying on screenshots and guesswork. Checkpoint:

• Payments, Members, and Receipts all agree on the same product and payment
• the success destination worked
• you trust the flow enough to show it to a real buyer

​

7. Publish where buyers already trust you

Publish the checkout link from the place the buyer already trusts:

• your Telegram bot or channel
• your Discord server
• your landing page
• an email, DM, or support follow-up

The strongest Hilt flows feel like a natural next step from the buyer’s existing community or funnel.

​

8. Add automation only after the flow is proven

Once the first live flow works, that is the right moment to bring in:

• API keys
• webhooks
• the SDKs
• Postman
• the CLI
• sandbox-based integration testing

The app should stay the commercial source of truth first.

​

15-minute launch checklist

Before you send real traffic:

• payout wallet is set
• checkout branding is set
• payment model is correct
• support URL is set
• first buyer payment or optional low-value live settlement check succeeded
• success destination is correct
• Payments, Members, and Receipts all updated

​

Common questions

​

What is the fastest safe way to launch Hilt?

Set workspace defaults, create one template, publish the checkout, validate the checkout and access trail, and confirm the payment, member, receipt, and support views are ready before wider traffic.

​

Should I create several templates before launch?

No. Build one product first, prove the full checkout and access trail, then duplicate the pattern once you know the buyer flow works.

​

Do I need a live test payment?

No. It is not required for the quickstart. Sandbox and dashboard checks should come first. A low-value live settlement check is optional when you want extra confidence in the real wallet, payout, receipt, and access path before real buyer traffic.

​

Where to go next

• Dashboard guide
• Templates
• Telegram flows
• Discord flows
• Payments and receipts
• Developer quickstart