Surcharge Payments
When surcharging is enabled on your account, the basic Tokenization
flow gains two extra steps: calling /rate after tokenization
to calculate the surcharge, then showing the customer the breakdown before they confirm payment.
Charging a flat amount without calling /rate first is non-compliant for surcharging merchants.
The customer must see and confirm the base amount, surcharge, and total before the charge is submitted.
All amounts are integers in cents (1000 = $10.00).
How it works
Code
Setup
-
Set up tokenization
Follow the Tokenization guide to load ZeroGateway.js and configure your card fields. For the surcharge flow, modify the
callbackto fetch the rate instead of sending the token directly to your charge endpoint:payment.js -
Fetch the surcharge rate
After tokenization, send the token, BIN and amount to your server, which calls the Strictly
GET /v1/public/payment/rateendpoint. It reads three query parameters:Parameter Type Description amountinteger Base amount in cents binCardstring First 6 digits of the card number tokenIdstring The single-use payment token ( response.token)The parameter is
tokenId, notpaymentToken. The rate call does not consume the token — only the charge does.payment.js — fetch rateOn your server. The example below uses Java, but this works the same in any server-side language:
RateController.java — Spring BootThe response:
CodeDebit cards typically return
debitRate: 0andsurcharge: 0. Always use thesurchargeandtotalAmountfrom the response — don't calculate them yourself.Obtaining
binCardThe tokenization callback returns
card: { number, exp, hash }— there is nobinfield. The BIN is the first 6 digits ofcard.number(the masked number keeps them:411111******1111→411111). On the Strictly gateway send bothtokenIdandbinCard; if the BIN cannot be derived, the token value is accepted as a fallback forbinCard. -
Show the customer the breakdown
Display the rate data before the customer can confirm. This is required for surcharging compliance:
payment.js — show review stepindex.html — review step -
Charge with the base amount
When the customer confirms, send the token, the masked card number and the base amount to your server, then charge with that base
amount. The API computes the surcharge server-side from the same BIN and adds it to the charged total, so it matches the/ratequote the customer saw. Never sendtotalAmountasamount: the surcharge would be applied twice.payment.js — confirm paymentThe example below uses Java, but this works the same in any server-side language:
ChargeController.java — Spring Boot
Charge requirements
When charging with a token, card.number (the masked number from the callback) is required
alongside card.paymentToken. Omitting it returns error 905. Charge request errors (902,
905, 906) use the code as the HTTP status as well, so do not expect a 400 for them:
905 — missing card number
Vault charges (card.vaultId) do not require /rate: the surcharge is computed server-side
from the eligibility stored on the payment method. See Customer Vault.
Non-surcharge accounts
If surcharging is not enabled on your account, skip /rate entirely — tokenize the card and charge
directly with the customer's entered amount. See Tokenization and
Quick Start.
Next steps
- Tokenization — full ZeroGateway.js setup reference
- Customer Vault — save a card so returning customers don't
re-enter details (vault charges compute the surcharge server-side, no
/rateneeded) - API Reference — GET /rate — full parameter and response schema

