# Decrypted Wallet Payloads

xMoney supports Apple Pay and Google Pay payments where your system sends an external payment network payload that has already been decrypted before the order request reaches xMoney.

Use this flow when your platform, payment orchestration provider, or wallet integration performs wallet token decryption and passes the payment network values to xMoney for authorization.

## Choose the right wallet flow

xMoney supports two server-side wallet submission patterns:

| Flow | Use when | Main fields |
|  --- | --- | --- |
| Encrypted wallet token | You want xMoney to decrypt the Apple Pay or Google Pay token. | `transactionOption.digitalWallet.walletType`, `transactionOption.digitalWallet.data` |
| Decrypted wallet payload | Your system already decrypted the wallet token. | `digitalWalletType`, `digitalWalletRawData`, `digitalWalletCryptogram`, `digitalWalletEci`, `digitalWalletProtocolVersion` |


This guide covers the decrypted wallet payload flow.

## Request fields

Send decrypted wallet payments through [`POST /order`](/api/reference/order/create-an-order) with `transactionMethod` set to `card`.

| Field | Required | Description |
|  --- | --- | --- |
| `digitalWalletType` | Yes | Wallet type. Accepted values are `googlePay` and `applePay`. |
| `digitalWalletRawData` | Yes | JSON string containing the decrypted external payment network payload. |
| `cardNumber` | Yes | Decrypted PAN from the wallet payload. |
| `cardExpiryDate` | Yes | Decrypted card expiry date in `MM/YY` format. |
| `digitalWalletCryptogram` | No | Wallet cryptogram from the decrypted payload. |
| `digitalWalletEci` | No | ECI from the decrypted wallet payload. |
| `digitalWalletProtocolVersion` | No | Wallet protocol version. For Google Pay, this is typically `ECv2`. |
| `cardHolderName` | No | Cardholder name. If omitted, xMoney applies a default cardholder name. |


When `digitalWalletType` is present, xMoney uses these top-level fields and does not decrypt `transactionOption.digitalWallet`.

`cardCvv` is not required for decrypted wallet payments.

## Google Pay example

```bash
curl -X POST "https://api-stage.xmoney.com/order" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "amount=10.00" \
  -d "currency=EUR" \
  -d "orderType=purchase" \
  -d "customerId=12345" \
  -d "transactionMethod=card" \
  -d "cardTransactionMode=authAndCapture" \
  -d "cardNumber=4111111111111111" \
  -d "cardExpiryDate=12/28" \
  -d "cardHolderName=Jane Doe" \
  -d "digitalWalletType=googlePay" \
  -d "digitalWalletCryptogram=AgAAAAAAAIR8CQrXcIhbQAAAAAA=" \
  -d "digitalWalletEci=05" \
  -d "digitalWalletProtocolVersion=ECv2" \
  -d "digitalWalletRawData={\"paymentMethodDetails\":{\"pan\":\"4111111111111111\",\"expirationMonth\":\"12\",\"expirationYear\":\"2028\",\"cryptogram\":\"AgAAAAAAAIR8CQrXcIhbQAAAAAA=\",\"eciIndicator\":\"05\"},\"protocolVersion\":\"ECv2\"}" \
  -d "ip=203.0.113.10"
```

For Google Pay, `digitalWalletRawData` should contain the decrypted payment method details returned by your decryption process, including the PAN, expiry, cryptogram, and ECI when available.

## Apple Pay example

```bash
curl -X POST "https://api-stage.xmoney.com/order" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "amount=10.00" \
  -d "currency=EUR" \
  -d "orderType=purchase" \
  -d "customerId=12345" \
  -d "transactionMethod=card" \
  -d "cardTransactionMode=authAndCapture" \
  -d "cardNumber=4111111111111111" \
  -d "cardExpiryDate=12/28" \
  -d "cardHolderName=Jane Doe" \
  -d "digitalWalletType=applePay" \
  -d "digitalWalletCryptogram=AgAAAAAAAIR8CQrXcIhbQAAAAAA=" \
  -d "digitalWalletEci=05" \
  -d "digitalWalletRawData={\"applicationPrimaryAccountNumber\":\"4111111111111111\",\"applicationExpirationDate\":\"281231\",\"paymentData\":{\"onlinePaymentCryptogram\":\"AgAAAAAAAIR8CQrXcIhbQAAAAAA=\"},\"eci\":\"05\"}" \
  -d "ip=203.0.113.10"
```

For Apple Pay, `digitalWalletRawData` should contain the decrypted payment data, including `applicationPrimaryAccountNumber`, `applicationExpirationDate`, `paymentData.onlinePaymentCryptogram`, and `eci` when available.

## Response handling

The create order response follows the standard `POST /order` response format. If the wallet transaction requires an additional authentication step, the response includes redirect details.

```json
{
  "code": 201,
  "message": "Created",
  "data": {
    "orderId": 67890,
    "transactionId": 123456,
    "is3d": 0,
    "isRedirect": false
  }
}
```

## Best practices

- Send decrypted wallet payloads only from a secure server-side environment.
- Do not expose decrypted PAN, cryptogram, or ECI values in browser logs, analytics, or client-side code.
- Keep using the encrypted `transactionOption.digitalWallet` flow when you want xMoney to perform wallet token decryption.
- Use [Network token payments](/guides/payments/network-token-payments) when your integration sends a scheme network token directly instead of a wallet payload.