Enter the card once. Pay in one tap from then on.
Waffo stores the card as a secure token, so the number never touches your system. Returning customers confirm with a tap; renewals charge in the background.
•••• 4242Expires 12/29
•••• 8817Expires 06/26
•••• 1005Expires 03/28Add new cardFirst time: type the card. Every time after: one tap.
The saved-card list, the confirm, and any extra verification are all Waffo's checkout, not your frontend.
The customer chooses to save the card while paying. It is stored only once that payment goes through — an attempt that failed leaves nothing behind.
Saved only once the payment succeeds.
One tap. 3DS can still be challenged when risk asks for it.
You hold a token. Waffo holds the card.
One-click runs on a stored card, but you never touch it. Which credential goes to the network is Waffo's call — not logic you have to write.
One token, one customer, one card
The token is scoped to that customer and that card under your Waffo account. It is not a card number and not a wallet, and it is worth nothing anywhere else. The card details stay with Waffo.
Unbinding is final
An expired token can be brought back rather than re-collected, and it can still be unbound. Unbinding is the end of it: a card the shopper adds again comes back as a new token.
One-click doesn't switch off risk
Waffo still decides which credential goes to the network, and still applies 3DS dynamically. A one-tap charge can be challenged like any other.
What you actually write.
Start a binding on your server. Submit the card from the browser. After that, it's your normal order call — with a token where the card number used to go.
Your server opens a tokenization session and gets back a session id. The API key never leaves your backend.
Read the tokenization guidePOST /api/v1/tokenization/generate { "tokenRequestId": "tkr_20260827_001", "merchantUserId": "USER_001", "tokenType": "CARD", "notifyUrl": "https://yourstore.com/webhooks/waffo" } # 200 -> { "tokenSessionId": "tks_9f2c..." } # Hand the session id to the browser. Your API key stays here.
The token plugs into the rest of the stack.
A saved credential is not a thing on its own — it lives on the checkout UI, is reused by every renewal, and still goes through the same risk checks on each charge.
Checkout
Prebuilt hosted and embedded payment UIs, or your own form — the credential one-click saves is the one those UIs reuse.
See checkoutSubscriptions
The same stored card is the one each renewal charges: plans, renewals, trials and receipts all sit on it.
See subscriptionsFraud prevention
A reusable credential does not skip risk — every charge is still assessed, and Waffo applies 3DS dynamically based on risk.
See fraud protectionFrequently asked questions about one-click payments.
No. What you store is a token scoped to that customer and card under your account. The card details stay with Waffo, and the token is worth nothing outside your account.
Their saved cards, and one confirm. A CVV field appears only on the one charge where a card-network token is not on file yet; after that charge it does not come back for that card. 3DS can still be challenged when risk asks for it.
You unbind it with the token you hold — which works even if that token has expired. The token is then canceled for good; a card the customer adds again comes back as a new token.
You are. Your terms have to say what you will charge, how often, how the amount is worked out, and how the customer cancels, and the customer has to agree to it. Waffo charges against the mandate that first payment created; it cannot write the terms for you.
If you are incorporated as a company, or if you are an individual developer.
Two paths, one promise: you build the product, Waffo runs the payments.