---
description: >-
  CARD payouts — pushing funds to a recipient's card using a cardTokenId
  obtained client-side through inyo.js, never from raw card data.
---

# Cards

A card payout sends funds to the recipient's card. The card itself is never named in the request — you send a **`cardTokenId`**, an opaque reference standing in for the card number.

| Field | Type | Required | Description |
|---|---|---|---|
| `type` | string | Yes | `"CARD"` |
| `countryCode` | string | Yes | ISO alpha-3 |
| `cardTokenId` | string | Yes | Tokenized card identifier — see [Getting a `cardTokenId`](#getting-a-cardtokenid) |

> Uzbekistan (`UZB`) is the one country whose schema is card-only. For other destinations, push-to-card is validated against the generic push schema rather than a country schema.

## Getting a `cardTokenId`

**Never send a raw card number to your own server.** Doing so pulls your backend into PCI DSS scope, and the gateway will not accept a PAN on `POST /v2/payment` in any case — the only card identifier the payment endpoint takes is a token.

Tokenization happens **in the recipient's browser**, before your backend sees anything:

```mermaid
sequenceDiagram
    participant U as Recipient's browser
    participant J as inyo.js
    participant T as Inyo tokenizer
    participant Y as Your backend
    participant G as Inyo Gateway

    U->>J: enters card details
    J->>T: card data (never touches your server)
    T-->>J: cardTokenId
    J-->>U: cardTokenId
    U->>Y: cardTokenId only
    Y->>G: POST /v2/payment<br/>paymentMethod.cardTokenId
```

The card data goes from the browser straight to the tokenizer. Your backend receives only the token, which is what you place in `recipient.paymentMethod.cardTokenId`.

See [Tokenizing cards](../../../tokenizing-cards.md) for the `inyo.js` setup, the script URL per environment, and the full client-side flow.

Two things catch integrations out:

- **The tokenizer response calls it `additionalData.token`, not `cardTokenId`.** That UUID is the value the payment request expects under `paymentMethod.cardTokenId` — the names differ across the two calls.
- **The origin loading `inyo.js` must be registered with Inyo first.** Tokenization requests from an unregistered page are rejected on CORS grounds, in sandbox as well as production. Send Inyo the full origin (e.g. `https://checkout.yoursite.com`) of every page that will call the tokenizer, before you go live.

> `inyo.js` ships as a separate build per environment, loaded from a different URL in sandbox and production — so keep the token, the script, and the API credentials on the same environment throughout.

## Example

```json
"recipient": {
  "firstName": "Jane",
  "lastName": "Doe",
  "paymentMethod": {
    "type": "CARD",
    "countryCode": "UZB",
    "cardTokenId": "778303bb-1441-4378-b923-77ecf414cffd"
  }
}
```

## What's Next

- [Tokenizing cards](../../../tokenizing-cards.md) — Produce a `cardTokenId` with `inyo.js`
- [Country coverage](../country-coverage.md) — Which corridors offer this method
- [Examples](../examples/README.md) — Complete request bodies