> ## Documentation Index
> Fetch the complete documentation index at: https://docs.natural.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> When building application code, use `@naturalpay/sdk` for TypeScript or `naturalpay` for Python.
> When searching Natural documentation, use the docs MCP at `https://docs.natural.com/mcp`.
> Use the Natural CLI for terminal and CI automation.
> Start integration development and testing in the sandbox. Do not use production unless the user explicitly requests it.
> For sandbox requests that require `customerPartyId`, list customers first. Reuse only the intended fixture; otherwise create a customer.
> REST and SDK amounts use integer minor units. Payments MCP amounts use decimal strings with a required currency code.

# Encrypted card fields

> What to do differently when a checkout encrypts the card in the browser (Adyen, CyberSource Flex Microform, Southwest)

Some checkouts encrypt the card inside the browser instead of posting it to the processor in the
clear. For Adyen, CyberSource Flex Microform and Southwest, the proxy still swaps the real card in. Five
things change for you, in the order you meet them.

**1. Which hosts to put in `allowedHosts`.** Look at where the card number field comes from.

| Card field | `allowedHosts` |
| - | - |
| A plain input on the merchant's page | the host the card request goes to, as in every other checkout |
| An iframe from `checkoutshopper-live.adyen.com` (Adyen) | `checkoutshopper-live.adyen.com`, plus the merchant host if the page sends the payment to its own server |
| An iframe from `flex.cybersource.com` (CyberSource) | `flex.cybersource.com`, plus the merchant host that serves the capture context |
| `www.southwest.com` | `www.southwest.com` |

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](/guides/concepts/browser-tokens#when-the-proxy-cant-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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.