@waffo/payment-sdk to bind a card independently on your page and securely convert the card data into a token. This flow does not require a regular payment in the same operation.
This flow spans both the server-side (calling the Generate / Inquiry / Remove APIs) and the frontend (submitting card information via
@waffo/payment-sdk).When to use this flow
- You need to bind a card before deciding when to charge it.
- You want to design the card-binding UI on your own page.
- You do not use Waffo Checkout, or do not want to bind the card as part of the current payment.
- You are building a merchant-managed subscription in which your system owns the billing schedule, subscription status, and failed-payment retries, and initiates each MIT.
Core flow
- Phase 1: bind the card — the merchant backend obtains
tokenSessionId, and the frontend submits card information through@waffo/payment-sdk. The returnedtokenIdhas theUNVERIFIEDstatus. This phase does not trigger 3DS. - Phase 2: zero-amount payment verification — the backend creates a zero-amount CIT with the token. This payment may require 3DS. After it succeeds, the token becomes
VERIFIED. - Subsequent payments — pass the
tokenIdaspaymentInfo.userPaymentAccessTokeninorder/create.
Card binding flow
1
Merchant backend calls the Generate API
Call POST /api/v1/tokenization/generate, passing parameters such as
tokenRequestId, merchantUserId, and tokenType: "CARD". On success, it returns tokenSessionId.2
Frontend submits card information
Use the The merchant frontend passes plaintext card data to the SDK, which encrypts the data before transmission. With merchant-side card binding, the merchant does not need PCI DSS certification as long as its backend neither retains nor transmits plaintext card data.
tokenizationSubmit method of @waffo/payment-sdk to encrypt the card data and submit it to the Waffo server:3
Handle the card binding result
notifyUrl, Waffo sends TOKENIZATION_NOTIFICATION when card binding completes, the Token status changes, or the card summary is updated. Process notifications idempotently using result.tokenId, and store the latest tokenStatus and Token data. The notification is not limited to the initial binding result.4
Create a zero-amount verification payment
The SDK card-binding phase does not trigger 3DS. After receiving an The zero-amount verification transaction is a CIT. Do not set
UNVERIFIED tokenId, call POST /api/v1/order/create, set orderAmount to 0, and pass the token as paymentInfo.userPaymentAccessToken.paymentInfo.merchantInitiatedMode. If the response has orderStatus: AUTHORIZATION_REQUIRED, parse orderAction and send the user to complete 3DS. Read the payment result from PAYMENT_NOTIFICATION. After payment succeeds, confirm that the token becomes VERIFIED through TOKENIZATION_NOTIFICATION or Tokenization Inquiry.Token status
After card binding succeeds, the Token starts inUNVERIFIED. Create a zero-amount ONE_TIME_PAYMENT CIT with that token. The payment may require the user to complete 3DS. After it succeeds, the token becomes VERIFIED.
UNVERIFIED: The Token exists but has not completed a successful CIT. You cannot use it for scheduled or unscheduled MIT; Waffo returnsA0045.VERIFIED: A successful CIT is complete, and the Token can be used for subsequent MIT payments.EXPIRED: The Token status becomesEXPIREDwhen the card reaches its expiry date.SUSPENDED: Waffo has suspended use of the Token. The public contract does not define the exact trigger conditions.
Initiate a subsequent MIT
CallPOST /api/v1/order/create. Use the same merchantUserId from the Generate API as userInfo.userId, and set both paymentInfo.userPaymentAccessToken and paymentInfo.merchantInitiatedMode.
-
scheduled: Charge on a pre-agreed fixed schedule. -
unscheduled: Merchant-initiated charge without a fixed schedule. MIT does not require the user to enter card information or complete 3DS again. Receive the result throughPAYMENT_NOTIFICATION. If the notification is not delivered, callPOST /api/v1/order/inquiryto retrieve the order status. Pass eitherpaymentRequestIdoracquiringOrderIdin the request body, for example:
tokenId only with Waffo’s ONE_TIME_PAYMENT product. Do not pass it to Waffo’s SUBSCRIPTION product.
Token API usage
Security mechanisms
- The merchant frontend passes plaintext card data to the SDK, which encrypts it before transmission; the merchant backend does not handle the plaintext card number
- All API requests and responses use SHA256WithRSA signature verification
- The first zero-amount CIT supports 3DS verification; the SDK card-binding phase does not trigger 3DS