0 · Inputs (shared)
Used by every method. Prefilled with the NetValve TEST card — safe on sandbox, but on
production it will be declined. Switch the environment to sandbox for a free dry run,
then re-run on production with a real card.
Secrets never reach this page: credentials are read from your macOS Keychain server-side.
A · Mint a saved-card token (real 3DS'd CARD sale)
Establish the control
A normal card payment with 3DS. Approves, and returns the
GATEWAY_TOKEN we vault —
the same shape production uses and the only one with production approvals.
B · Charge the SAVED token (the actual question)
B.1 · Without 3DS — what production ships today
paymentType=TOKEN + ECOMMERCE, no 3DS, no stored-credential flag.
This is the current post-fix envelope that has never been tried on production.
If this approves, tokenization works and nothing else is needed.
B.2 · 3DS init over the saved token
/3ds/v2/initialization takes ThreeDSInitAndAuthInputDTO, which requires
paymentType and accepts paymentToken, customerIp and the
browser fields. Two gotchas found against the live sandbox: browser fields are mandatory
(else 3DS_2006) and customerIp must be routable — documentation ranges like
203.0.113.x are refused with a misleading GTW_2007.
B.3 · /sale over the token + the 3DS block
The resumed sale after authentication: the vaulted
paymentToken plus the
3DS block captured in B.2. Run B.2 first — the block is filled in automatically.
paymentType is decisive here. TOKEN names the token kind and
approves. CARD is production's HPF shape (which omits paymentType and
lets the gateway infer HPF from a bare token) — against a vaulted token that inference
fails with GTW_2109 "Invalid Hosted payment Fields Data or TokenizationKey".
C · /rebill against the original sale
No token, no 3DS
References the original SALE transactionID (not a rebill's own id — that fails
GTW_2013). Proven on our MID, but so far only for memberships. Paste an anchor
from Method A.2's transactionID, or from the NetValve backoffice.
D · Token creation (read-only, no charge)
Compare token provenance
verify=false mints without contacting the issuer;
verify=true does a $0 authorisation. Compare the resulting
paymentTokenType with what Method A mints.
What the results mean
Measured on sandbox (2026-09-24):
- B.1 approves without 3DS → tokenization already works; the CIT-flag removal was the fix.
- B.2 + B.3 (paymentType=TOKEN) approve → saved tokens work, and 3DS over a saved token is a viable route. confirmed on sandbox
- B.3 with paymentType=CARD fails
GTW_2109→ the token kind must be named explicitly; do not reuse the HPF (paymentType-less) shape over a vaulted token. confirmed on sandbox - C.1 approves →
/rebillworks with no token and no 3DS, but it is anchored to an original sale, so it suits repeat/unattended charges rather than a fresh CIT.
Read
bankTransactionId / authCode in every response.
both empty = rejected inside the gateway (envelope problem).
populated = the issuer answered (a real card/account decision).
Request / response log
0