How PSPs Add Stablecoin Payments Without a Crypto Licence

The request usually arrives the same way. You process for a few hundred merchants, and every month, a few more ask whether they can take USDC. They want their customers to pay in stablecoins, and they want to be paid out in their own currency, as they always have been.

What you want is narrower. No crypto on your balance sheet. No licence application takes eighteen months. Something that bolts onto the stack you already run, under your brand, with the regulated crypto activity sitting on someone else's permissions.

That is a normal request, and it has a normal answer. Here is how the pieces fit.

 

Three models sit behind the phrase, and they carry very different obligations.

 

Almost every PSP asking this question wants the first model. The merchant sees a new payment method and a normal payout. The stablecoin exists for a few minutes in between, on infrastructure you did not have to license.

The third model is where the licensing burden lives. Holding customer crypto, even briefly on your own books, is usually the line between "we distribute a regulated service" and "we are the regulated entity". Avoiding that line is the entire design goal for most PSPs.

 

This is the first question any regulator, bank, or auditor will ask, and it determines most of the rest. If stablecoins never sit in an account you control, your role looks much closer to distribution than to custody.

Structure the flow so that conversion happens at the provider, and the only thing that reaches you is fiat and a payment record.

 

If merchants are paid in their local currency, the stablecoin is a rail rather than a product. Most merchants asking for this want exactly that. They are not asking to hold digital assets. They are asking to accept a customer who wants to pay with one.

Paying merchants in stablecoin is a different business with different conversations about treasury, volatility policy, and accounting.

 

Somebody in the chain needs permissions for the crypto leg. It can be you, which is slow and expensive, or it can be a partner whose licence you distribute under. White-label arrangements exist precisely so the brand stays yours while the regulated activity stays theirs.

Get this written down early. "Who is the regulated party for the crypto conversion?" is the question your bank will ask, and an unclear answer is how banking relationships get reviewed.

None of this is legal advice, and the scope varies by jurisdiction and by how your contracts are drafted. Have counsel confirm the structure before launch.

Also Read: How Transak abstracts the messy middle of stablecoin payments

 

Ask a merchant why they want stablecoin acceptance and the answer is rarely about the technology. Test any proposal against three things:

1. Fewer chargebacks. A settled stablecoin payment cannot be reversed by the payer's bank sixty days later. For merchants in categories that carry heavy dispute rates, that is the whole pitch.
2. Better economics on cross-border sales. A customer paying from another country normally arrives through card rails with an interchange cost and an FX spread. A stablecoin payment can shorten that path.
3. Faster access to money. Settlement in minutes rather than days changes working capital, particularly for merchants with thin margins and fast inventory cycles.

If a proposal does not improve at least one of those, the merchant is asking for a checkout badge rather than a payment method, and it will stay a rounding error in your volume.

The corollary matters just as much. Merchants should not have to learn which chain a payment used, and neither should their staff. If your rollout requires training a shop on wallets and networks, the design is wrong.

 

This is the part that surprises PSP teams, and it cuts both ways.

Stablecoin transfers are final. There is no issuer-driven chargeback and no forced reversal sixty days later. That removes a large category of merchant loss.

It also means a refund is a new outbound payment, not a reversal of the original. That has consequences worth designing for.

• You need a funded path to send refunds, which means the merchant either holds a balance or you pull from their fiat settlement.
• The refund amount may not equal the original if the payment was converted through fiat and the merchant is refunding later.
• A customer who paid from an exchange account may give you a deposit address that cannot receive a refund correctly.

Write the refund flow before launch. Teams that treat it as a phase-two problem discover it during their first dispute.

 

Every additional stablecoin and every additional network multiplies your support load, your reconciliation cases, and the number of ways a customer can send funds to the wrong place.

Start with the assets your merchants' customers actually hold, on the networks where fees are low, and confirmation is fast. Two assets and two or three networks cover the overwhelming majority of real volume. Expand when a merchant asks, and the volume justifies it, not in advance.

The same discipline applies to the checkout. A payment page that asks a customer to choose a network is a payment page with a drop-off problem.

 

Your merchants will expect the same reporting they get for cards. Which order, which payment, which payout, and what the fees were.

That is harder with stablecoins because an on-chain transfer carries an amount and an address rather than an order reference. The fix is to generate the reference yourself, pass it to your provider when the payment is created, and store the returned payment ID against the order immediately. Our guide to reconciling stablecoin payments into an AP system covers the mechanics in detail.

Also plan for the fee and FX lines. If a payment converts on its way to the merchant, the amount they receive will not match the amount the customer sent, and your statement needs to show why.

 

Building means acquiring permissions for the crypto leg, setting up custody or arranging it, integrating liquidity for conversion, and owning sanctions screening and transaction monitoring on the asset side. It is a multi-year programme and a permanent operating cost.

Partnering means integrating an API, agreeing on where the regulated boundary sits, and keeping your brand at the front. The trade is margin and control in exchange for time and scope.

For a PSP with a few hundred merchants and growing demand, the calculation is usually straightforward. The reason to build is if stablecoin settlement becomes the product rather than a feature of it.

Also Read: How apps embed crypto and stablecoin payments

 

We provide the regulated crypto leg so you do not have to hold it. Payments convert at our end, your merchants are paid in fiat through our off-ramp, and the flow stays white-labelled under your brand.

Identity and sanctions screening run on our side on every transaction, and if you have already verified your merchants, you can pass that through rather than making them verify twice. Every payment returns an ID and a settlement webhook, which is what makes merchant reporting work without a monthly matching exercise.

 

Adding stablecoin acceptance is mostly an exercise in deciding what you are not going to do. Do not hold the asset. Do not apply for permissions you do not need. Do not ask merchants to understand blockchains.

Start with one question and let the answers follow from it. Write down whether stablecoins will ever sit in an account you control. If the answer is no, most of the licensing complexity leaves with it, and what remains is an integration.

Then pick three merchants who have already asked, and run them live before you build anything general.

 

It depends on whether you hold the asset. If stablecoins never enter an account you control and conversion happens at a licensed partner, the regulated crypto activity generally sits with that partner. Taking custody, even briefly, usually brings you into scope. Confirm your specific structure with counsel.

 

The stablecoin is converted at the provider and the merchant receives a normal fiat payout to their bank account. The merchant never holds crypto and does not need a wallet. From their side it behaves like any other payment method with a settlement cycle.

 

A refund is a new outbound payment rather than a reversal, because settled transfers are final. You need a funded route to send it, either from a merchant balance or deducted from their fiat settlement, and a policy for what the refund amount is when the original payment was converted.

 

There is no issuer-initiated chargeback in the card sense, because the payer's bank cannot claw back a settled on-chain transfer. Merchants still handle disputes and goodwill refunds directly, so the operational work does not disappear. What disappears is forced reversal and the associated loss.

 

Start with the one or two assets your merchants' customers actually hold, on two or three networks with low fees and fast confirmation. Every extra asset and chain adds support tickets, reconciliation cases, and ways for customers to send funds incorrectly. Expand only when volume justifies it.

 

Yes, and it is the standard arrangement for PSPs. The checkout, the merchant dashboard, and the support relationship stay under your brand while the regulated crypto activity runs on the provider's permissions. Agree in writing which party is the regulated entity for each leg of the flow.

 

Integrating a partner API is typically weeks rather than months, and the timeline is usually set by your compliance review and merchant agreements rather than by engineering. Building the crypto leg in-house is a multi-year programme once permissions, custody, liquidity, and monitoring are included.

 

Generate a unique reference for each payment in your own system, pass it to the provider when creating the payment, and store the returned payment ID against the order straight away. The settlement webhook then updates the record automatically, which avoids matching by amount and date at month-end.