How to build a crypto card app like RedotPay
How a stablecoin card really works: what happens between the tap and the answer, how the crypto is converted and held, what each module does, and the licences on each side.
A crypto card app is a stablecoin wallet with a payment card attached. Users top up in crypto, and when they pay, the app converts just enough of their balance into the shop's currency at that moment. To build one you need four things: wallets that hold customers' crypto, a card programme on Visa or Mastercard, a platform that decides and converts each payment in under a second, and the licences, or licensed partners, for both the crypto side and the card side.
This guide is general information, not legal advice: the details depend on your services and your market, so confirm them with a lawyer and the regulator before you apply.
What an app like RedotPay does
RedotPay describes itself as a stablecoin-based payment fintech whose platform lets people spend and send digital assets. In July 2026 it reported more than eight million users and over $1bn in monthly payment volume. The product behind those numbers is simple to describe:
A wallet. Each user holds stablecoins and other crypto in the app, with a deposit address on every network the app supports.
A card. A virtual card is ready at sign-up, a physical one follows on request, and both go into Apple Pay and Google Pay.
Spending. The card works anywhere cards are accepted. The user never sells crypto by hand: the app does it at the moment of payment.
Sending. Users pay out to bank accounts and wallets, in local currency, on local payment rails.
How the money gets in
A card can only spend what the wallet holds, so the story starts with a deposit.
An address of their own. The user picks a coin and a network in the app and gets a deposit address, created through your custody provider or your own keys.
Confirmed and screened. The transfer is spotted on the chain. Once it has the confirmations you require for that network and its source passes screening, it counts.
Credited. The user's balance goes up in your ledger and can be spent straight away. The same stablecoin on two networks is two separate balances.
From then on the crypto stays where it is, in custody. What moves when the user pays is a number in your ledger.
How a card payment works, step by step
For the user, a payment is a tap. For you, the operator, it is a question your platform has to answer in real time. Here is the whole of it, in order.
Before the first payment
When a user passes verification, your platform creates a virtual card on your issuer's processor, and it shows in the app at once. One tap adds it to Apple Pay or Google Pay: the processor supplies the encrypted card data, and the network's token service gives the phone a token in place of the card number, so the phone pays with the token.
The request
The tap. The user pays at a till or online, and the shop's terminal sends the payment to the shop's own payment provider, the acquirer.
The network. The acquirer passes it to Visa or Mastercard, which finds the issuer of the card.
The processor. The network routes the request, called an authorisation, to your issuer's processor. The processor asks your platform one question: approve or decline?
The decision
Your platform now does four things, in under a second.
It checks. Is the card frozen? Is the balance enough? Is the payment inside the user's limits, and inside the rules you set for kinds of shop and countries? Your fraud rules and fraud engines score the payment at the same moment and return one decision: allow, ask for a second factor, hold or block.
It converts. The platform takes the first coin with enough balance, in the order the user chose. It reads live prices from your liquidity providers, adds your margin and fixes the rate. The conversion is booked at once at that rate. Nothing waits for a provider: the platform covers its position with them in the background, one conversion at a time or netted in a batch.
It holds the amount. The converted amount is put on hold in your ledger. The user's available balance drops immediately, before any money has moved, so the same balance cannot be spent twice.
It answers. Approved or declined goes back the way the request came: processor, network, acquirer, terminal. The user sees a receipt with the amount, the coin, the rate and the fee.
If your platform cannot answer in time, a fallback agreed for your programme applies: the processor stands in on its own checks, or the payment is declined. That is why this path deserves the most engineering care. A slow answer is a declined card in front of a queue.
After the tap
An approval is a promise, not yet a payment. Two more things happen later.
Clearing. The final record of the payment arrives from your processor. The hold is released and the payment is booked for good as balanced entries in the ledger, with your fee on your revenue accounts. Reversals and adjusted amounts arrive the same way and are booked the same way.
Settlement. The shop is paid in its own currency, as with any card. It never sees crypto. Each day your ledger is reconciled with the processor's settlement files and with the blockchains, entry by entry, and any difference waits for a person in the backoffice.
Refunds and reversals are never edits. A refund is booked as new entries that reverse the original, so the history shows both. A disputed payment is worked in your backoffice, and the processor raises the chargeback with the shop's acquirer under the network's rules.
What each module does in that second
Every step above belongs to a module. This is how they share the work.
Module | Its part in a payment |
|---|---|
Custody and wallets | Holds the keys and the coins, gives each user deposit addresses, and screens deposits and withdrawals |
KYC and AML | Verifies the user before the first card, screens against sanctions lists, and keeps screening afterwards |
Card issuing | Creates the card, puts it in the phone's wallet, and decides each authorisation with the user's limits and controls |
Fraud and risk | Scores every payment in milliseconds and holds the doubtful ones for an analyst |
FX | Quotes the rate with your margin, books the conversion at once and covers it with liquidity providers |
Ledger | Holds the amount, books every payment twice as debits and credits, and reconciles the day |
Payouts | Sends money out to bank accounts and wallets on local rails, with the rate held while the user confirms |
Backoffice | Where your team sees every user, card and case, with roles, two-person approval and an audit log |
The ledger is the piece the rest stands on. Crypto and fiat sit in the same set of books, so a card payment that converts a stablecoin is one set of balanced entries, not two systems to reconcile.
What you need beyond the software
A card programme. Payment cards are issued by a licensed issuer, such as a bank or an e-money institution, that is a member of Visa or Mastercard. Most crypto card brands start as programme managers: a licensed issuer, often called a BIN sponsor (the bank identification number is the first digits of every card), issues the cards under its licence, with your brand on the card and in the app. The issuer and its processor review your company, and the card network approves the programme. Our guide to BIN sponsorship covers that route.
Custody. Whoever holds the keys to customers' crypto needs a licence or registration for custody: you, or a custody provider. Most new apps start with a provider.
Liquidity and payouts. Conversion needs one or more liquidity providers to trade with. Sending money to bank accounts needs payout partners that reach local rails, such as SEPA Instant in the euro area or Pix in Brazil. Each provider checks your company before signing you as a client.
The phone wallets. Your issuer enables your cards for Apple Pay and Google Pay, and Apple and Google approve adding cards from inside your app.
The licences on each side
A crypto card is two regulated businesses in one app: issuing payment cards, and holding and converting crypto for customers. Each market licenses the two sides separately.
Market | The crypto side | The card side |
|---|---|---|
EU | Authorisation as a crypto-asset service provider (CASP) under MiCA, the Markets in Crypto-Assets Regulation, or a CASP partner | A licensed issuer, such as a bank or an e-money institution |
UK | Registration with the Financial Conduct Authority (FCA) under the Money Laundering Regulations, then FCA authorisation under the new regime | An e-money institution or a bank as issuer |
UAE | A crypto licence from VARA, the DFSA, the FSRA or the Capital Market Authority, depending on where you operate | A stored value facility licence from the Central Bank, or a licensed partner |
A few points decide more than the rest:
In the EU, the transitional periods are over. MiCA's last transitional periods ended on 1 July 2026. Holding, converting and sending crypto for customers needs CASP authorisation, or a partner that provides those services under its own. Your app must not present you as a CASP if you are not one.
Stablecoins are not all equal in the EU. A single-currency stablecoin is an e-money token, and it can be offered only if its issuer is an authorised bank or e-money institution. On 6 October 2026, the register kept by ESMA, the European Securities and Markets Authority, listed Circle's USDC and EURC, and not USDT.
In the UK, the regime is changing. Crypto firms register with the FCA before they start, and authorisation under the Financial Services and Markets Act is expected from 25 October 2027. See FCA cryptoasset registration.
In the UAE, the regulator depends on the address. Dubai outside the DIFC is VARA's, the DIFC is the DFSA's, ADGM is the FSRA's. See the stored value facility licence.
The order to build it in
Choose the market and the licence route. Your own licences, or licensed partners for cards and for crypto. This decides which coins you may offer and to whom.
Start the partner conversations early. The issuer, the custody provider and the liquidity provider each review your company. Their approvals, not the software, usually set the date real customers can pay.
Build the wallet and the ledger first. Deposits, balances and a ledger that always agrees with what is on-chain are the foundation.
Add the card. Connect the issuer processor, answer authorisations in real time, and add card controls.
Add conversion. Live quotes, your margins, and each user's order of coins.
Add payouts. Bank accounts and wallets, with the rate held while the user confirms.
Run it. A backoffice with roles, two-person approval for sensitive actions, fraud cases and an audit log.
Common mistakes
Treating the card approval as a formality. The card network approves each programme, and its date is the launch date.
Building conversion before the ledger. Without holds on a ledger, the same balance can be spent twice.
Forgetting what happens after the approval. Clearing, refunds and disputes arrive days later and have to land in the same books.
Offering every stablecoin everywhere. What you may offer depends on the market.
What this means for your platform
Paynoramic's white-label crypto card app is assembled from modules already in production: custody and wallets on providers such as Fireblocks, BitGo, Copper, Cobo or Ledger Enterprise, or on your own hardware security modules; card issuing on issuer processors such as Marqeta, Thredd, Nium, Paymentology, Enfuce or Galileo; FX for conversion with your margins; payouts; KYC and AML with wallet screening; a double-entry ledger for crypto and fiat, reconciled daily; fraud and risk; and the backoffice.
The software takes about 30 days. The licences and the card programme approval run alongside it, often take longer, and usually set the date real customers can pay. We help you choose issuers and custodians that work with crypto, and help you get each contract. At launch you receive the full source code, with no licence fee and no revenue share. We are not lawyers: your counsel decides the licences, and we configure the platform to match.
