allowedHosts. Look at where the card number field comes from.
Nothing else: the user sees the list on the approval page. A checkout that encrypts for a processor not
listed here can’t be paid with a browser token yet; use the fallback in
when the proxy can’t reach the checkout.
2. When to create the session. Reach the payment page first, then create the session, get approval
and claim. A claim is single-use and expires within 15 minutes; a failed attempt needs a new session.
Once claimed, reload the payment page (or re-open the card form) so the processor’s card fields load
through the proxy: that load tells the proxy which merchant key the card is encrypted for. Without it,
an Adyen merchant request carrying the card is refused with
card_proxy_adyen_checkout_unknown.
3. What to route through the proxy. Only requests to the hosts above, never the whole browser:
merchants rate-limit the proxy’s address when all page traffic comes from it. The processor’s card
request leaves from inside its iframe, so attach your request interception to that frame as well as the
top page, and relay the merchant request whose body carries the ciphertext (Adyen) or returns the capture
context (CyberSource). Typing works as usual: focus the field and type the stand-in digits from the claim.
4. How to know the swap happened. The merchant’s confirmation or receipt showing the real card’s
last four. A 200/201 from the processor is not proof: it tokenizes the stand-in just as happily, and
the merchant declines later. A CyberSource token JWT exposes content.paymentInformation.card.number.maskedValue,
so you can check it before pressing Pay.
5. 3DS. If the issuer asks for a one-time code, it went to the user’s phone. Ask the user for it;
don’t retry the purchase.