How and why to accept crypto payments, with AI prompts to set it up

Most businesses start asking how to accept crypto payments for a simple reason: customers ask for it. Someone in another country can’t get their card through, a B2B client would rather settle an invoice in USDC than wait on a wire, or a subscriber already keeps most of their savings in dollars on-chain. Usually the real question is whether customers who already hold digital dollars can pay you with them, and what that takes on your side.

At the end of this guide there are prompts you can paste into ChatGPT, Claude or any coding assistant to read our documentation for you, check the fit for your business and plan the integration.

When accepting crypto makes sense

In practice, accepting crypto today mostly means accepting stablecoins. USDC and USDT are pegged to the US dollar, so the price you charge is the amount you receive, without the volatility that made early Bitcoin checkouts a headache for finance teams. There are around $300 billion of stablecoins in circulation, according to DefiLlama.

Stablecoin payments tend to fit a few kinds of business well. International sellers get a way for customers in markets where card payments are expensive or unreliable to pay in dollars from a wallet they already use. Businesses that invoice other businesses get settlement in minutes instead of the days a cross-border wire can take. Subscriptions and digital goods get another way to pay for customers who would rather not use a card.

There are limits. If your customers don’t hold stablecoins, adding them won’t create demand on its own. A stablecoin payment is also final once it confirms. There are no chargebacks in the card sense, which removes a category of fraud, and a refund is a new transfer back to the customer.

What to check before you choose a provider

Once you decide to accept stablecoins, four questions will tell providers apart.

The first is custody. Many gateways receive your customers’ payments into wallets they control and pay you out later, which means your revenue sits on their balance sheet in between. Woldy is built the other way: every branch of your business has its own segregated vault, and we have no way to move the funds inside it. We wrote about why in segregated by design.

The second is what happens when a customer makes a mistake, especially paying on the wrong network. Ask whether the checkout makes the customer copy an address and pick a network themselves. If it does, expect support tickets. We covered this in detail in what happens when a customer sends USDT or USDC on the wrong network.

The third is gas. On most networks, sending tokens requires a separate native token to pay the network fee, and a customer who holds USDC but no ETH can’t pay. On Woldy, network fees are covered, so the customer only needs the stablecoin they already have.

The fourth is how payment results reach your systems: whether you get webhooks, a clear set of statuses, and your own order reference on every payment. Our due-diligence checklist goes through these and a few more in detail.

How the setup works

There are two ways to start, and you can use both.

The no-code route is a payment link created in the Merchant Dashboard. You set the amount and a deadline, copy the link and send it to a customer. It takes under a minute and suits one-off payments, invoices and testing the flow yourself.

The API route is for checkouts that run automatically. Your server creates a payment link with the order amount and your own order ID, then redirects the customer to the hosted checkout URL that comes back. On that page the customer connects their wallet through WalletConnect, reviews the amount and signs. Your system listens for webhooks and fulfils the order once the payment link is marked completed. The docs estimate around 30 minutes for a developer to get this working, and the full flow is described in the payment links guide.

Payments land in the vault of the branch that created the link. From there, you settle funds to that branch’s own wallet manually or on rules you set, either when the balance reaches a threshold or on a schedule. The details are in how vaults and settlement work.

How reconciliation works

Reconciliation is where crypto payments usually get messy. A transfer on a block explorer doesn’t say which order it was for, and a “pending” status in a gateway dashboard doesn’t tell finance whether the money will ever arrive. Woldy keeps two records apart, one for what you asked for and one for what was paid.

What you asked for lives on the payment link: the amount, the deadline and your own order ID, passed as external_id when the link is created. What was paid lives on a charge. Every payment attempt creates one, and it records the token, the amount, the network and the time it confirmed. One link can collect several charges, because a customer whose wallet disconnects or whose balance is too low simply tries again. At most one charge per link ends up completed, and that one is the money.

Matching a payment to an order then takes one lookup. You keep the mapping from your order ID to the payment link when you create it, and the charges API returns every attempt made against that link. The same API answers the questions a month-end close usually needs: completed charges for a given period, revenue by collection method, and any payment that arrived without a request, which Woldy flags as unexpected so finance can review those payments as a separate list. A payment returned to the customer after it confirmed shows up as refunded, while the link it paid stays completed.

For a live feed, charge events arrive as each attempt starts, confirms, fails or is refunded, which makes them the right source for reconciliation and reporting. Orders should still be fulfilled on the payment link’s own completed event. A failed charge means one attempt didn’t go through, and the customer can still pay.

On the settlement side, each branch keeps its own vault and wallet, so revenue from different stores, brands or regions reconciles separately from the start, and the Vault page shows the balance on each network before you settle it.

Let your AI assistant read the docs

Our documentation publishes an llms.txt file, a plain index that AI assistants can read to find every guide and API page. That means you don’t have to read the docs yourself to understand what Woldy is or how to integrate it. Paste one of the prompts below into ChatGPT, Claude, Gemini or a coding assistant such as Claude Code or Cursor, and fill in the parts in square brackets.

If your assistant can’t open links, open the llms.txt file yourself and paste its contents, plus any pages it points to, into the chat.

Prompt 1: understand what Woldy is

Use this if you own payments or finance and want a straight explanation before talking to anyone.

Read https://docs.woldy.xyz/llms.txt and the pages it links to.

Then explain to me, in plain language and without marketing wording:
1. What Woldy is and what it is not.
2. Who holds the funds at each step, from the moment a customer pays until the money reaches my own wallet.
3. Which stablecoins and networks are supported, and what a customer needs in order to pay.
4. How fees are charged, with a worked example.
5. How a payment is matched back to an order, and what data finance can pull for a month-end close.
6. What is available today and what is marked as coming soon.

Finish with a list of questions I should ask the Woldy team that the documentation does not answer. Quote the docs where you can, and say clearly when something is not covered.

Prompt 2: check the fit for your business

Use this to decide whether stablecoin payments are worth adding at all.

I run [describe your business: what you sell, B2C or B2B].
My customers are mostly in [countries or regions].
Typical payment size: [amount]. Payment type: [one-off / subscriptions / invoices].
Today I accept: [cards, bank transfers, other methods], and the main problems are [declines, fees, slow settlement, anything else].

Using the Woldy documentation at https://docs.woldy.xyz/llms.txt, assess whether accepting USDC and USDT through Woldy makes sense for me.

Cover:
- Which of my customers are likely to use it and which are not.
- What would change for checkout, customer support and finance operations.
- How I would structure branches if I run several stores, brands or regions.
- Limitations and risks I should know about, including what Woldy does not support.

Be specific to my business and do not recommend it if the case is weak.

Prompt 3: plan and build the integration

Use this in a coding assistant inside your project. Replace the stack with your own.

I want to accept USDC and USDT payments in my [framework and language, e.g. Next.js with TypeScript] app using Woldy payment links.

Read https://docs.woldy.xyz/llms.txt, then the Payment Links guide, the Charges guide and the Webhooks guide it links to. Use only what the docs describe and do not invent endpoints or fields.

Plan the integration first, then implement it:
1. On checkout, create a payment link on the server with the order amount, an expiry, my order ID as external_id and a return_url.
2. Redirect the customer to the payment_url from the response.
3. Add a webhook endpoint that verifies the signature as described in the docs.
4. Fulfil the order only on payment_link.completed, and make fulfilment idempotent so a repeated event cannot fulfil twice.
5. Show a "payment in progress" state while the link is PROCESSING, and handle EXPIRED and CANCELLED.
6. Keep the API key on the server in an environment variable and never expose it to the browser.

Show me the plan and list anything the docs leave unclear before you write code. Then write the code and tests for the webhook handler.

Prompt 4: review an integration before launch

Use this once the integration works, before real customers see it.

Here is my Woldy integration code: [paste the relevant files or point the assistant to them].

Check it against the Woldy documentation at https://docs.woldy.xyz/llms.txt and list every problem you find, most serious first. In particular, check that:
- the API key is never sent to the client or committed to the repository;
- webhook signatures are verified before anything else happens;
- orders are fulfilled only on payment_link.completed, never on PROCESSING;
- fulfilment is idempotent;
- my order ID is passed as external_id and used to match payments back;
- expired and cancelled links are handled without leaving orders stuck;
- failed charges are treated as retries, not as lost orders.

For each problem, show the fix.

Prompt 5: build a daily reconciliation report

Use this in a coding assistant once payments are live, or hand it to whoever owns finance tooling.

I accept payments through Woldy payment links. Read https://docs.woldy.xyz/llms.txt, then the Charges guide and the Payment Links guide it links to. Use only what the docs describe.

Build a daily reconciliation job in [language] that:
1. Fetches all charges created in the previous day using the charges list endpoint with created_from and created_to, handling pagination.
2. Matches each charge to my order through reference.id and the payment link I stored against my order ID (external_id).
3. Compares what was asked for on the payment link with what was paid on the completed charge: amount, token and network.
4. Produces a report with these sections:
   - orders marked as paid in my system with no completed charge;
   - completed charges with no matching order;
   - charges flagged as unexpected;
   - refunded charges;
   - any amount mismatch between the link and the charge.
5. Exports the report as CSV and totals completed revenue per token and per network.

My orders are stored in [database or system]. Ask me for the schema before writing the matching logic, and list anything the docs leave unclear.

Where to start

The quickest way to judge the whole flow is to try it as your customer would. Create an account in the Merchant Dashboard, make a small payment link, and pay it from your own wallet. Then run the second prompt with your real numbers, pass the third one to whoever owns your checkout, and set up the reconciliation report before your first busy week. The get started guide covers the account and API key setup step by step.