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 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

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

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.

{
  "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 when your integration sends a scheme network token directly instead of a wallet payload.