Apple Pay™

apple pay logo
Apple Pay™ is a digital wallet that allows customers to pay using credit or debit cards saved in their Apple Wallet. Instead of sharing card details directly with the merchant, Apple Pay generates a secure payment token representing the customer's payment information. This tokenization process helps protect sensitive card data during the transaction.
Apple Pay enables customers to perform fast and secure payments with a single interaction on websites using Safari, or in iOS and macOS applications, using any card linked to their Apple Wallet.

How Apple Pay Works with Getnet

When a customer chooses Apple Pay during checkout, the following flow occurs:

  1. The customer selects Apple Pay as the payment method.
  2. Apple Pay returns payment data containing tokenized card credentials or an encrypted Apple Pay payment token.
  3. The merchant sends the required Apple Pay payment data to Getnet as part of the payment request.
  4. Getnet processes the transaction through the configured payment processor or card network.
  5. The authorization result is returned to the merchant.

Integration Overview

To process Apple Pay payments with Getnet, the integration involves two main components:

  1. Integrating the Apple Pay API in your application or website.
  2. Sending the required Apple Pay payment data to Getnet for payment processing.
After integrating with Apple Pay, you can display the Apple Pay button in your checkout and request payment information from your customers.

If you offer Apple Pay as a payment method to your customers, use only official Apple Pay brand assets according to Apple's brand guidelines. Do not modify the colors, proportions, layout, or appearance of Apple Pay assets.

Requirements

Before integrating Apple Pay, ensure the following:

  • Apple Pay payment with Getnet is available only in Brazil and Spain.
  • Your integration complies with the Apple Pay Acceptable Use Guidelines and Terms of Service.
  • Your frontend environment must be served over HTTPS to initialize Apple Pay on the Web.
  • Before going live, you must complete domain verification and the required certificate setup in the Apple Developer Portal.
  • Your backend must be able to send the required payment data to Getnet according to the selected processing scenario.

Integration Steps

Step 1: Integrate with Apple Pay

Follow Apple's official documentation to implement Apple Pay:

This integration allows your checkout to display the Apple Pay button and request payment data from the user's Apple device or Apple Wallet.

Step 2: Configure your Apple Pay account

Before moving to production, you must configure Apple Pay in the Apple Developer Portal and coordinate the certificate setup with your Getnet account manager.

Depending on your integration model, this may include:

  1. Create a Merchant ID — a unique identifier for your business.
  2. Domain verification — host the apple-developer-merchantid-domain-association file provided by Apple at https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association.
  3. Payment Processing Certificate:
    1. Contact your Getnet account manager to request the Apple Pay Payment Processing Certificate setup.
    2. Getnet will generate and provide the Certificate Signing Request, also known as CSR, required for Apple Pay.
    3. In the Apple Developer Portal, go to your Merchant ID settings and select Create Certificate under Payment Processing Certificate.
    4. Upload the CSR file provided by Getnet.
    5. Apple generates a .cer file.
    6. Download the .cer file from the Apple Developer Portal and send it back to your Getnet account manager to complete the certificate setup.
  4. Merchant Identity Certificate — generate this certificate to allow your server to authenticate with Apple's servers during Merchant Validation.
  5. Confirm the supported card networks and merchant capabilities.

These steps ensure your website or application is authorized to request Apple Pay payments.

Step 3: Validate the merchant session

For Apple Pay on the Web, your frontend must perform Merchant Validation before the Apple Pay payment sheet is displayed.

The frontend receives a validationURL from Apple Pay and sends it to your backend. Your backend performs an authenticated request to Apple using the Merchant Identity Certificate and returns the merchant session to the frontend.

Step 4: Process the payment

Once the customer authorizes the payment:

  1. Apple Pay returns payment data to the merchant.
  2. Your system sends the required Apple Pay payment data to Getnet.
  3. Getnet processes the transaction through the configured payment processor or card network.
  4. Getnet returns the authorization result to the merchant.

Merchant Validation

Merchant Validation is required for Apple Pay on the Web.

Before the Apple Pay payment sheet appears, your frontend must start an Apple Pay session. The onvalidatemerchant event is triggered when the session starts.
Your frontend sends the validationURL received from Apple Pay to your backend. Your backend then performs an authenticated POST request to Apple's servers using your Merchant Identity Certificate.
Apple returns an opaque merchantSession object. Your backend must return this object to the frontend unchanged.

Backend request to Apple

Your backend must POST to the validationURL received from the frontend using a TLS connection authenticated with your Merchant Identity Certificate.
FieldDescriptionExample
merchantIdentifierYour Apple Merchant ID."merchant.com.your-store"
displayNameName shown on the Apple Pay sheet. Maximum 64 characters."Your Store"
initiativeUse "web" for Apple Pay on the Web."web"
initiativeContextFully qualified domain that hosts the checkout."checkout.yourdomain.com"
The TLS connection must present your Merchant Identity Certificate issued by Apple. Apple rejects calls that are not authenticated by this certificate.
information icon
Note: Each merchantSession is valid for a short period and is single-use. Do not cache or reuse merchant sessions.

Frontend handler

javascript
session.onvalidatemerchant = async (event) => { // Send event.validationURL to your backend. // The backend completes the authenticated request to Apple // and returns Apple's merchantSession object. const merchantSession = await callYourBackend(event.validationURL); session.completeMerchantValidation(merchantSession); };

Backend example

javascript
import https from 'https'; import fs from 'fs'; async function validateMerchant(validationURL) { const cert = fs.readFileSync('./merchant_identity.pem'); const key = fs.readFileSync('./merchant_identity.key'); const body = JSON.stringify({ merchantIdentifier: 'merchant.com.your-store', displayName: 'Your Store', initiative: 'web', initiativeContext: 'checkout.yourdomain.com' }); const response = await fetch(validationURL, { method: 'POST', body, headers: { 'Content-Type': 'application/json' }, agent: new https.Agent({ cert, key }) }); return response.json(); }

Apple Pay payment data and Getnet processing models

Apple Pay returns payment data that can be processed in different ways depending on the merchant architecture, PCI scope, certificate management strategy, and payment processing requirements.

The Apple Pay payment data defines what Apple returns to the merchant. The Getnet processing model defines how the merchant sends that data to Getnet.

These are different concepts and should not be mixed:

ConceptWhere it is configured or usedExamples
Apple Pay payment dataApple Pay frontend and token responseDevice Account Number, payment cryptogram, encrypted pkPaymentToken
Getnet processing modelServer-side payment request sent to GetnetDAN card data flow, Cryptogram card data flow, Authorization Token flow

Use the sections below to understand the Apple Pay payment data and the Getnet processing models available for each integration.

Device Account Number

Apple Pay may provide a Device Account Number, also known as DAN, after the Apple Pay payment token is decrypted by the merchant or merchant-side processor.

The DAN is a tokenized representation of the customer's card stored in Apple Wallet. It is not the customer's real PAN.

When using this data, the server-side payload sent to Getnet may follow one of these processing models:

  • DAN card data flow: the merchant or merchant-side processor decrypts the Apple Pay token, extracts the DAN and expiration date, and sends them to Getnet as structured card fields.
  • DAN card data flow with 3DS: the merchant or merchant-side processor decrypts the Apple Pay token, extracts the DAN and expiration date, performs 3DS authentication when required, and sends the card and 3DS fields to Getnet.

If 3D Secure authentication is required by local regulation, issuer rules, merchant configuration, or transaction risk, an additional 3DS flow may be triggered.

3DS for DAN transactions

For DAN transactions, 3D Secure may be required depending on the country, merchant configuration, issuer rules, or transaction risk.

information icon

For Spain, 3DS/SCA is required. For Brazil, 3DS may be optional depending on merchant configuration and risk rules.

To process a DAN transaction with 3DS, merchants must follow the standard Getnet 3DS authentication flow before creating or confirming the payment. After authentication is completed, send the 3DS authentication fields in the payment request, such as eci, xid, ucaf, tdsver, and tdsdsxid, according to the Create a 3DS Authenticated Payment documentation.

If 3DS is required and the authentication data is not provided, the transaction may be declined or returned as pending for additional authentication.

Payment cryptogram

Apple Pay may provide tokenized device card credentials with a payment cryptogram after the Apple Pay payment token is decrypted by the merchant or merchant-side processor.

The payment cryptogram, such as TAVV or the applicable network cryptogram, is generated during the payment process and provides stronger authentication evidence because it is generated for the tokenized device credential.

When using this data, the server-side payload sent to Getnet may follow this processing model:

  • Cryptogram card data flow: the merchant or merchant-side processor decrypts the Apple Pay token, extracts the DAN, expiration date, payment cryptogram, and ECI, and sends these values to Getnet as structured payment fields.

Additional 3D Secure authentication is generally not required for this flow, unless required by regulation, issuer rules, merchant configuration, or transaction risk.

Authorization Token flow

Authorization Token is a Getnet processing model used when the merchant sends the Apple Pay payment token to Getnet instead of decrypting the token and sending card data fields separately.

Use this flow when your backend sends the Apple Pay payment token to Getnet in data.payment.wallet.authorization_token.
In this flow, extract the pkPaymentToken returned by Apple Pay, serialize it exactly as returned, encode it in Base64, and send the encoded value in data.payment.wallet.authorization_token.

Getnet processes the token and extracts the payment data required for authorization.

information icon
Important: Apple Pay's Authorization Token must be encoded in Base64. Do not decrypt, change, trim, or remove any field from the token content before encoding it.
Do not mix models in the same request. If you send data.payment.wallet.authorization_token, do not also send card.number, card.expiration_month, card.expiration_year, tokenization.cryptogram, or tokenization.eci.

Choosing a processing model

Merchants can choose the processing model that best fits their integration architecture, PCI scope, certificate management strategy, and payment processing requirements.

CriteriaRecommended processing model
You want Getnet to process the Apple Pay token and do not want to decrypt the token in your environment.Authorization Token flow
You can decrypt Apple Pay tokens server-side and operate within the required PCI-DSS scope.DAN card data flow or Cryptogram card data flow
You need to send a device-generated payment cryptogram as structured fields.Cryptogram card data flow
You need to process DAN with a separate 3DS authentication flow.DAN card data flow with 3DS
You need to process SDWO transactions in Brazil.SDWO card data flow or SDWO Authorization Token flow
If unsure, start with Authorization Token flow, because Getnet processes the Apple Pay token and the merchant does not send card or tokenization fields separately.

Decrypting the Apple Pay payment token

The DAN card data flow and Cryptogram card data flow require the merchant or merchant-side processor to decrypt the Apple Pay payment token before sending data to Getnet.

Apple Pay does not return the DAN or payment cryptogram in plaintext directly to the frontend. These values are available only after the Apple Pay payment token is decrypted.

Decryption uses the Payment Processing Certificate private key configured for the merchant. After decrypting the token, extract the required fields from the decrypted payload and map them to the Getnet payment request.
Apple Pay decrypted fieldGetnet fieldNotes
applicationPrimaryAccountNumberdata.payment.card.numberDevice Account Number, also known as DAN. Do not send the customer's real PAN.
applicationExpirationDatedata.payment.card.expiration_year, data.payment.card.expiration_monthReturned as YYMMDD. Use the first two characters for expiration_year and the next two characters for expiration_month.
paymentData.onlinePaymentCryptogramdata.payment.tokenization.cryptogramPayment cryptogram generated for the Apple Pay transaction. Send the value exactly as returned after decryption.
paymentData.eciIndicatordata.payment.tokenization.eci or data.payment.eciElectronic Commerce Indicator associated with the transaction.
information icon
PCI scope: Decrypting the Apple Pay token brings tokenized card credentials into your environment. The decryption service must operate within the appropriate PCI-DSS scope. If this is not feasible, use the Authorization Token flow.

For the full decrypted token schema, refer to Apple's Payment Token Format Reference.

Payment acceptance

Merchants can process Apple Pay payments using multiple Getnet backend scenarios, including DAN card data flow, Cryptogram card data flow, Authorization Token flow, and SDWO-specific transactions.

You must define the payment capabilities and card networks you accept in your Apple Pay request according to the methods supported by your integration.

Apple Pay dataCredential type3DS requirementSupported countries
Device Account NumberTokenized card credential associated with Apple WalletRequired in Spain. Optional in Brazil depending on merchant configuration and transaction risk.Brazil and Spain
Payment cryptogramTokenized device card credential with payment cryptogramGenerally not required, unless required by regulation, issuer rules, merchant configuration, or transaction risk.Brazil and Spain
Apple Pay payment tokenEncrypted pkPaymentToken returned by Apple PayHandled according to token content and configuration.Brazil and Spain

Cards

Cards available for the transaction.

TypeSpainBrazil
Mastercard
Visa
You must define the card networks you accept in supportedNetworks, based on the networks supported by your integration.
AttributeTypeDescriptionExample
merchantCapabilitiesArrayPayment capabilities supported by the merchant.["supports3DS"]
supportedNetworksArrayCard networks supported by Apple Pay and Getnet.["masterCard", "visa"]

The following is an example of how to support the available card networks:

json
{ "merchantCapabilities": ["supports3DS"], "supportedNetworks": ["masterCard", "visa"] }

Billing address

information icon
Note: Request billing address only when required for authorization, fraud prevention, AVS, or local compliance. Asking for additional information may increase checkout friction.
Use requiredBillingContactFields to request billing address fields from Apple Pay when required for authorization, fraud prevention, AVS, or local compliance.
AttributeTypeDescriptionExample
requiredBillingContactFieldsArrayBilling contact fields to request from the customer.["postalAddress", "name"]
requiredShippingContactFieldsArrayShipping contact fields to request from the customer, when applicable.["postalAddress", "name", "phone", "email"]
json
{ "requiredBillingContactFields": ["postalAddress", "name"], "requiredShippingContactFields": ["postalAddress", "name", "phone", "email"] }

Handling the Apple Pay payload

When a customer pays with Apple Pay, Apple returns payment data in the PKPaymentToken object.

For the Authorization Token flow, the Apple Pay payment token must be extracted from:

text
payment.token

The merchant must then:

  1. Extract the pkPaymentToken returned by Apple Pay.
  2. Serialize the token exactly as returned by Apple Pay.
  3. Encode the serialized token in Base64.
  4. Send the encoded value in data.payment.wallet.authorization_token in the Getnet payment request.

Do not decrypt, change, trim, or remove any field from the token content before encoding it.

information icon
Encoding note: The tokenization.cryptogram field used in the Cryptogram card data flow is sent as extracted after token decryption. By contrast, the authorization_token field used in the Authorization Token flow must contain the Base64-encoded Apple Pay payment token.
Example of Base64-encoding the pkPaymentToken in Node.js:
javascript
const authorizationToken = Buffer .from(JSON.stringify(pkPaymentToken), 'utf8') .toString('base64');

Example of the Getnet payment request using the Authorization Token flow:

json
{ "data": { "amount": 500, "currency": "EUR", "payment": { "payment_method": "CREDIT", "transaction_type": "FULL", "number_installments": 1, "wallet": { "id": "103", "type": "10", "authorization_token": "<BASE64_ENCODED_APPLE_PAY_PAYMENT_TOKEN>" } } } }

Integrate via Global API

To integrate Apple Pay via the Global API, ensure the following prerequisites are met:

  • Generate an access token through the Authentication endpoint.
  • Wallet configuration: Use the correct wallet.id, wallet.type, and wallet.tag according to the selected Apple Pay processing scenario.
  • PCI Compliance: Scenarios involving card objects, such as DAN card data flow and Cryptogram card data flow, require the merchant to operate within the appropriate PCI-DSS scope for handling tokenized card data. If the merchant uses the Authorization Token flow, Getnet processes the Apple Pay token and the merchant must not send card or tokenization fields separately.
  • HTTPS: Your frontend environment must be served over a secure connection to initialize Apple Pay on the Web.

Wallet field configuration

Use the table below to identify the correct wallet configuration for each scenario.

Scenariodata.payment.wallet.iddata.payment.wallet.typedata.payment.wallet.tag
Standard Apple Pay — DAN card data flow10310Not required
Standard Apple Pay — Cryptogram card data flow10310Not required
Authorization Token flow10310Not required
SDWO card data flow10355Not required
SDWO Authorization Token flow10355AP
information icon
Important: For standard Apple Pay transactions, use wallet.id = 103 and wallet.type = 10.
For SDWO card data transactions in Brazil, use wallet.id = 103 and wallet.type = 55.
For SDWO Authorization Token transactions, use wallet.id = 103, wallet.type = 55, and wallet.tag = AP.

Characteristics

CapabilityDetails
Customer ExperienceOne-Tap — Fast checkout via Face ID, Touch ID, or passcode.
SettlementReal-time — Transactions are authorized and settled according to card network rules.
ConfirmationSynchronous — The API provides an immediate APPROVED, DECLINED, or intermediate status such as PENDING when additional authentication is required.
Device SupportLimited to compatible Apple devices using Safari browser or iOS/macOS apps.

Available Features

Use the matrix below to confirm the supported operations for Apple Pay in the Global API.

FeaturesSupported CountriesPurchasesRefundsPartial RefundsPre-authorizations3DSSDWO
Direct / APIBrazil and SpainBrazil only

Integration Flow

The lifecycle of an Apple Pay transaction begins with the frontend requesting Apple Pay payment data and ends with the server-side authorization call.

Transaction Flow Diagram

The following diagram illustrates the end-to-end payment flow when a customer completes a purchase using Apple Pay and the payment is processed through Getnet.

Flow Description

  1. The customer selects Apple Pay as the payment method at checkout.
  2. The merchant application starts the Apple Pay session.
  3. For Apple Pay on the Web, the merchant performs Merchant Validation.
  4. Apple validates the merchant and returns a merchant session.
  5. The Apple Pay sheet is displayed to the customer with their saved payment methods.
  6. The customer selects a card and authorizes the payment using Face ID, Touch ID, or passcode.
  7. Apple Pay generates and returns payment data to the merchant.
  8. The merchant sends the required Apple Pay payment data to Getnet.
  9. Getnet prepares the transaction according to the selected processing scenario.
  10. Getnet sends the authorization request to the card network or configured payment processor.
  11. The processor returns the authorization result.
  12. Getnet forwards the response to the merchant, which then displays the final payment result to the customer.

Server-Side Implementation Scenarios

The following scenarios detail the JSON structures required based on the data provided by Apple Pay and the selected Getnet processing scenario.

information icon
Important: Device Account Number, payment cryptogram, and pkPaymentToken are Apple Pay payment data concepts. They are not Getnet server-side scenario names.
In the Getnet payment request, merchants can choose the processing model that best fits their integration architecture, PCI scope, certificate management strategy, and payment processing requirements: DAN card data flow, Cryptogram card data flow, Authorization Token flow, SDWO card data flow, or SDWO Authorization Token flow.

DAN card data flow

Use this server-side scenario when your backend decrypts the Apple Pay payment token and sends the Device Account Number, also known as DAN, to Getnet as structured card fields.

This flow is used when the backend payload sent to Getnet is a structured card payment request.

In this model, the merchant or merchant-side processor decrypts the Apple Pay payment token, extracts the DAN and expiration date, and sends these values to Getnet.

If 3D Secure authentication is required, the merchant must complete the 3DS authentication flow before creating or confirming the payment, and send the required 3DS fields in the payment request.

AttributeTypeDescriptionExample
data.payment.cardObjectCard data set.--
data.payment.card.numberStringDevice Account Number, also known as DAN. Do not send the customer's real PAN.4012001037141112
data.payment.card.expiration_monthStringTwo-digit card expiry month.12
data.payment.card.expiration_yearStringTwo-digit card expiry year.25
data.payment.walletObjectWallet data set.--
data.payment.wallet.idStringWallet identifier. For Apple Pay, always use 103.103
data.payment.wallet.typeStringWallet type. For standard Apple Pay transactions, use 10.10
data.payment.eciStringElectronic Commerce Indicator used for 3DS authentication. Optional for transactions without 3DS.02
information icon
Important: For Spain, 3DS authentication is required. In Brazil, 3DS is optional depending on merchant configuration, issuer rules, and transaction risk.

Example of request

json
{ "idempotency_key": "63c7f8ee-51a6-470d-bb76-ef762b62bfb7", "request_id": "daac03dc-73db-453f-9bea-b1391669d5d3", "order_id": "ORDER-10187383", "data": { "amount": 500, "currency": "BRL", "customer_id": "02587894152", "payment": { "payment_id": "{{$guid}}", "payment_method": "DEBIT", "transaction_type": "FULL", "number_installments": 1, "card": { "number": "4012001037141112", "expiration_month": "09", "expiration_year": "30" }, "wallet": { "id": "103", "type": "10" } }, "additional_data": { "customer": { "phone_number": "5511999999999", "email": "customer@example.com", "document_number": "50506468000", "document_type": "CPF", "name": "Jose da Silva", "billing_address": { "street": "Rua A", "number": "1", "district": "Centro", "city": "Sao Paulo", "state": "SP", "country": "BR", "postal_code": "05781000", "complement": "N/A" } } } } }

Example of response

json
{ "idempotency_key": "e61674fa-f50c-46e0-a7e4-3adb048d423f", "seller_id": "a9c99f03-025c-4261-a9f5-de73ef593623", "payment_id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d", "order_id": "ORDER-10187383", "amount": "500", "currency": "BRL", "status": "APPROVED", "payment_method": "DEBIT", "received_at": "2026-04-08T17:14:54.000Z", "transaction_id": "MCC00KJ50408", "original_transaction_id": "MCC00KJ50408", "authorized_at": "2026-04-08T17:14:55.717Z", "reason_code": "00", "reason_message": "captured", "acquirer": "GETNET", "soft_descriptor": "EC TESTES PAGONXT - NA", "brand": "VISA", "authorization_code": "810172", "acquirer_transaction_id": "000454195865" }

DAN card data flow with 3DS

Use this server-side scenario when your backend decrypts the Apple Pay payment token, sends the DAN as structured card data, and includes 3DS authentication fields.

For DAN transactions that require 3D Secure authentication, complete the 3DS authentication flow first as described in the Create a 3DS Authenticated Payment documentation. Then include the 3DS result fields in the payment request.

AttributeTypeDescriptionExample
data.payment.xidStringMPI identifier for each authenticated transaction.yFNXIadjt0mEsP5ob44vQPd0Zbg=
data.payment.ucafStringUCAF authentication code.B5kBAHNwQAAAAYdqmGESdiZwFVg=
data.payment.eciStringElectronic Commerce Indicator.05
data.payment.tdsverString3DS version.2.3.1
data.payment.tdsdsxidString3DS Server transaction identifier.9c2410c8-07c7-4e07-ac76-185e620970cf
information icon
Note: Send the 3DS fields returned by your authentication provider according to the card network and authentication result.

Example of DAN with 3DS request

json
{ "idempotency_key": "63c7f8ee-51a6-470d-bb76-ef762b62bfb7", "request_id": "daac03dc-73db-453f-9bea-b1391669d5d3", "order_id": "ORDER-10187383", "data": { "amount": 500, "currency": "EUR", "customer_id": "12345678Z", "payment": { "payment_id": "173f9e8d-4e0b-4503-8016-5cdafba89bee", "payment_method": "CREDIT", "transaction_type": "FULL", "number_installments": 1, "xid": "yFNXIadjt0mEsP5ob44vQPd0Zbg=", "eci": "05", "tdsver": "2.3.1", "tdsdsxid": "9c2410c8-07c7-4e07-ac76-185e620970cf", "card": { "number": "4012001037141112", "expiration_month": "09", "expiration_year": "30" }, "wallet": { "id": "103", "type": "10" } }, "additional_data": { "customer": { "phone_number": "+34911234567", "email": "customer@example.com", "document_number": "12345678Z", "document_type": "DNI", "name": "Jose da Silva", "billing_address": { "street": "Calle Mayor", "number": "10", "district": "Centro", "city": "Madrid", "state": "Madrid", "country": "ES", "postal_code": "28013", "complement": "N/A" } } } } }

Example of DAN with 3DS response

json
{ "idempotency_key": "63c7f8ee-51a6-470d-bb76-ef762b62bfb7", "seller_id": "a9c99f03-025c-4261-a9f5-de73ef593623", "payment_id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d", "order_id": "ORDER-10187383", "amount": "500", "currency": "EUR", "status": "APPROVED", "payment_method": "CREDIT", "received_at": "2026-04-08T17:14:54.000Z", "transaction_id": "MCC00KJ50408", "original_transaction_id": "MCC00KJ50408", "authorized_at": "2026-04-08T17:14:55.717Z", "reason_code": "00", "reason_message": "Transaction authorized (payment/preauthorization)", "acquirer": "GETNET", "brand": "VISA", "authorization_code": "810172", "acquirer_transaction_id": "000454195865" }

SDWO — Staged Digital Wallet Operator

SDWO is a payment framework typically used by digital wallet providers where the wallet acts as an intermediary between the cardholder and the final recipient.

It facilitates two stages: funding the account and transferring funds to a sub-merchant. This ensures transparency of the end receiver for payment networks.

For SDWO transactions in Brazil, the fields inside the wallet object must be filled as follows:
  • data.payment.wallet.id must be set to 103
  • data.payment.wallet.type must be set to 55
AttributeTypeDescriptionExample
data.payment.cardObjectCard data set.--
data.payment.card.numberStringDevice Account Number, also known as DAN.4012001037141112
data.payment.card.expiration_monthStringTwo-digit card expiry month.12
data.payment.card.expiration_yearStringTwo-digit card expiry year.25
data.payment.walletObjectWallet data set.--
data.payment.wallet.idStringWallet identifier. For Apple Pay, always use 103.103
data.payment.wallet.typeStringWallet type for SDWO transactions. Always use 55.55
data.payment.wallet.fund_transferObjectFund transfer data required for SDWO transactions.--
information icon
Note: SDWO fund transfer fields follow the SDWO-specific format and may use different value domains than the standard customer object.

Example of SDWO request

json
{ "idempotency_key": "{{$guid}}", "request_id": "{{$guid}}", "order_id": "{{$guid}}", "link_id": "{{$guid}}", "data": { "amount": 1200, "currency": "BRL", "payment": { "payment_id": "{{$guid}}", "payment_method": "CREDIT", "save_card_data": false, "transaction_type": "FULL", "number_installments": 1, "dynamic_mcc": 6051, "card": { "number": "4012001037141112", "expiration_month": "12", "expiration_year": "29" }, "wallet": { "type": "55", "id": "103", "fund_transfer": { "pay_action": "FT", "receiver": { "account_number": "9999999999999995", "account_type": "00", "first_name": "Jane", "middle_name": "T", "last_name": "Smith", "addr_street": "1 Main ST", "addr_city": "SAO PAULO", "addr_state": "SP", "addr_country": "BRA", "addr_postal_code": "1408000", "nationality": "BRA", "phone": "5511977778888", "date_of_birth": "19901230", "id_type": "03", "id_num": "12345678900000" }, "sender": { "account_number": "9999999999999995", "account_type": "00", "first_name": "Jane", "middle_name": "T", "last_name": "Smith", "addr_street": "1 Main ST", "addr_city": "SAO PAULO", "addr_state": "SP", "addr_country": "BRA", "addr_postal_code": "1408000", "nationality": "BRA", "phone": "5511977778888", "date_of_birth": "19901230", "id_type": "03", "id_num": "12345678900000" } } } } } }

Example of SDWO response

json
{ "idempotency_key": "855294c3-61d0-4da9-a3e4-f6038b92cd76", "seller_id": "a9c99f03-025c-4251-a9f5-de73ef593523", "payment_id": "4eaab005-5cdc-41eb-8598-6e36aaa1bb85", "order_id": "cc44fe82-2712-453c-948b-52e346216e43", "amount": "1200", "currency": "BRL", "status": "APPROVED", "payment_method": "CREDIT", "received_at": "2026-05-12T18:04:21.000Z", "transaction_id": "016132078327616", "original_transaction_id": "016132078327616", "authorized_at": "2026-05-12T18:04:32.953Z", "reason_code": "00", "reason_message": "captured", "acquirer": "GETNET", "soft_descriptor": "EC TESTES PAGONXT - NA", "brand": "VISA", "authorization_code": "030603", "acquirer_transaction_id": "000421185086" }

SDWO with 3DS Transactions

For transactions using 3DS, please follow all the steps provided in the Create a 3DS Authenticated Payment document.

information icon
Important: When creating SDWO requests, the fields inside the wallet object must be filled as follows:
  • data.payment.wallet.id must be set to 103
  • data.payment.wallet.type must be set to 55

The table below shows the fields required for transactions with 3DS.

AttributeTypeDescriptionExample
data.payment.xidStringMPI identifier for each authenticated transaction.yFNXIadjt0mEsP5ob44vQPd0Zbg=
data.payment.ucafStringAuthentication code encrypted by the card network.B5kBAHNwQAAAAYdqmGESdiZwFVg=
data.payment.eciStringElectronic Commerce Indicator used for 3DS authentication.5
data.payment.tdsverString3DS version used in authentication.2.3.1
data.payment.tdsdsxidString3DS Server transaction identifier.9c2410c8-07c7-4e07-ac76-185e620970cf

Example of SDWO with 3DS request

json
{ "idempotency_key": "{{$guid}}", "request_id": "{{$guid}}", "order_id": "{{$guid}}", "link_id": "{{$guid}}", "data": { "amount": 1000, "currency": "BRL", "payment": { "payment_id": "{{$guid}}", "payment_method": "CREDIT", "save_card_data": false, "transaction_type": "FULL", "number_installments": 1, "dynamic_mcc": 6051, "xid": "dyZb2stPifAatR7aaQufcNBgshE=", "ucaf": "j0V7ephXEz91CBEEwhFpACkAAAA=", "eci": "2", "tdsver": "2.3.1", "tdsdsxid": "790cb396-97b4-5a03-8000-0000104ec36b", "card": { "number": "5555555555554444", "expiration_month": "12", "expiration_year": "32" }, "wallet": { "type": "55", "id": "103", "fund_transfer": { "pay_action": "FT", "receiver": { "account_number": "9999999999999995", "account_type": "00", "first_name": "Jane", "middle_name": "T", "last_name": "Smith", "addr_street": "1 Main ST", "addr_city": "SAO PAULO", "addr_state": "SP", "addr_country": "BRA", "addr_postal_code": "1408000", "nationality": "BRA", "phone": "5511977778888", "date_of_birth": "19901230", "id_type": "03", "id_num": "12345678900000" }, "sender": { "account_number": "9999999999999995", "account_type": "00", "first_name": "Jane", "middle_name": "T", "last_name": "Smith", "addr_street": "1 Main ST", "addr_city": "SAO PAULO", "addr_state": "SP", "addr_country": "BRA", "addr_postal_code": "1408000", "nationality": "BRA", "phone": "5511977778888", "date_of_birth": "19901230", "id_type": "03", "id_num": "12345678900000" } } } } } }

Example of SDWO with 3DS response

json
{ "idempotency_key": "c26015f2-a412-4ddb-a126-6742b6acdc70", "seller_id": "a9c99f03-025c-4251-a9f5-de73ef593523", "payment_id": "5d11ac09-3343-4654-80f7-28a9f46dc25d", "order_id": "6753f130-c8fd-4faf-8e5a-424d777aedaa", "amount": "1000", "currency": "BRL", "status": "APPROVED", "payment_method": "CREDIT", "received_at": "2026-05-12T17:39:32.000Z", "transaction_id": "MCC00CVWL0512", "original_transaction_id": "MCC00CVWL0512", "authorized_at": "2026-05-12T17:39:33.281Z", "reason_code": "00", "reason_message": "captured", "acquirer": "GETNET", "soft_descriptor": "EC TESTES PAGONXT - NA", "brand": "MASTERCARD", "authorization_code": "108850", "acquirer_transaction_id": "000932182031", "eci": "2" }
information icon
The response follows the same structure as the standard payment response. If additional authentication is required, the transaction may return PENDING with 3DS challenge data.

Cryptogram card data flow

Use this server-side scenario when your backend decrypts the Apple Pay payment token and sends tokenized card credentials with a payment cryptogram to Getnet as structured payment fields.

In this model, the merchant or merchant-side processor extracts the Device Account Number, also known as DAN, together with the expiration date, payment cryptogram, and ECI, and sends these values to Getnet.

If you use the Authorization Token flow, do not send card.number, card.expiration_month, card.expiration_year, tokenization.cryptogram, or tokenization.eci separately. In the Authorization Token flow, Getnet processes the Apple Pay token sent in data.payment.wallet.authorization_token.

The payment cryptogram is a dynamically generated cryptographic value that enables payment networks to validate the authenticity of the transaction.

AttributeTypeDescriptionExample
data.payment.cardObjectCard data set containing the tokenized card credentials extracted from Apple Pay.--
data.payment.card.numberStringDevice Account Number, also known as DAN. Do not send the customer's real PAN.4761120000000148
data.payment.card.expiration_monthStringTwo-digit expiry month of the tokenized card credential.12
data.payment.card.expiration_yearStringTwo-digit expiry year of the tokenized card credential.25
data.payment.walletObjectWallet data set.--
data.payment.wallet.idStringWallet identifier. For Apple Pay, always use 103.103
data.payment.wallet.typeStringWallet type. For standard Apple Pay transactions, use 10.10
data.payment.tokenizationObjectTokenization data set containing cryptographic values extracted from Apple Pay.--
data.payment.tokenization.cryptogramStringPayment cryptogram generated for the Apple Pay transaction. Send the value exactly as extracted after token decryption. Do not generate, alter, or reuse cryptograms.AgAAAAAABk4DWZ4C28yUQAAAAAA=
data.payment.tokenization.eciStringElectronic Commerce Indicator associated with the tokenized payment.02

Example of request

json
{ "idempotency_key": "f6e5cb13-a5fe-46f9-b467-29bd13c29e59", "request_id": "d808b53a-aa47-4484-8c99-cbe83624474c", "order_id": "izgyekkmb8sd", "data": { "amount": 500, "currency": "EUR", "customer_id": "12345678Z", "payment": { "payment_id": "izgyekkmb8sd", "payment_method": "CREDIT", "transaction_type": "FULL", "number_installments": 1, "card": { "number": "4761120000000148", "expiration_month": "12", "expiration_year": "49" }, "wallet": { "id": "103", "type": "10" }, "tokenization": { "cryptogram": "AgAAAAAABk4DWZ4C28yUQAAAAAA=", "eci": "02" } }, "additional_data": { "customer": { "phone_number": "+34911234567", "email": "customer@example.com", "document_number": "12345678Z", "document_type": "DNI", "name": "Jose da Silva", "billing_address": { "street": "Calle Mayor", "number": "10", "district": "Centro", "city": "Madrid", "state": "Madrid", "country": "ES", "postal_code": "28013", "complement": "N/A" } } } } }
information icon
The cryptogram value above is shown only as an example. In production, send the cryptogram value exactly as extracted from the decrypted Apple Pay payment token. Do not generate, alter, reuse, or hardcode cryptograms.

Example of response

json
{ "idempotency_key": "2e7b86be-201d-4a82-a8f9-7102500faf78", "seller_id": "7c966bb3-a8dc-4428-aa95-61081719ed80", "payment_id": "omczgrvmxdt5", "order_id": "omczgrvmxdt5", "amount": "500", "currency": "EUR", "status": "APPROVED", "payment_method": "CREDIT", "received_at": "2026-02-23T15:10:52.664Z", "original_transaction_id": "", "authorized_at": "2026-02-23T15:10:53.688Z", "reason_code": "00", "reason_message": "Transaction authorized (payment/preauthorization)", "acquirer": "GETNET", "brand": "UNKNOWN" }
information icon
Note: In sandbox environments, the brand field may be returned as UNKNOWN depending on the test token configuration.

Authorization Token flow

The Authorization Token flow is a Getnet processing model used when the merchant sends the Apple Pay payment token to Getnet instead of decrypting the token and sending card data or tokenization data as separate fields.
When a customer pays with Apple Pay, Apple returns an encrypted pkPaymentToken containing the payment data.
In this model, the merchant does not send card.number, card.expiration_month, card.expiration_year, tokenization.cryptogram, or tokenization.eci as separate fields. Instead, the merchant must extract the pkPaymentToken returned by Apple Pay, serialize it exactly as returned, encode it in Base64, and send the encoded value in data.payment.wallet.authorization_token.
Getnet processes the authorization_token and extracts the payment data required for authorization.
information icon
Important: Apple Pay's Authorization Token must be encoded in Base64. Do not decrypt, change, trim, or remove any field from the token content before encoding it.
AttributeTypeDescriptionRequired
idempotency_keyStringUnique identifier to prevent duplicate charges.Yes
order_idStringMerchant reference ID used for reconciliation.Yes
request_idStringTrace identifier for idempotency audits and support follow-up.Recommended
data.amountNumberTransaction amount in cents.Yes
data.currencyStringISO currency code used in the transaction.Yes
data.customerObjectCustomer details such as name, email, phone, document, and billing address. Required only when requested by Getnet or by the applicable risk, compliance, or antifraud configuration.Conditional
data.payment.payment_methodStringPayment method used for the transaction.Yes
data.payment.transaction_typeStringDefines how the transaction is processed. Examples: FULL, INSTALL_NO_INTEREST, INSTALL_WITH_INTEREST.Yes
data.payment.number_installmentsNumberNumber of installments. Use 1 for a single payment.Yes
data.additional_data.deviceObjectDevice information used for risk analysis or antifraud checks when applicable, such as ip_address, device_id, and finger_print.Conditional
data.payment.walletObjectWallet data set.Yes
data.payment.wallet.idStringWallet identifier. Use 103 for Apple Pay.Yes
data.payment.wallet.typeStringWallet type. Use 10 for standard Apple Pay Authorization Token transactions or 55 for SDWO Authorization Token transactions.Conditional
data.payment.wallet.tagStringWallet tag. Required only for SDWO Authorization Token transactions. Use AP.Conditional
data.payment.wallet.authorization_tokenStringBase64-encoded Apple Pay payment token. Send the token content exactly as returned by Apple Pay, encoded in Base64, without decrypting, changing, trimming, or removing any field.Yes

Depending on the risk, compliance, or antifraud service enabled for the merchant, additional customer and device information may be requested. When required, send the applicable fields below.

Object / FieldDescription
customer.first_nameCustomer's first name.
customer.last_nameCustomer's last name.
customer.emailCustomer email address.
customer.phone_numberPhone number in international format.
customer.document_typeDocument type, such as CPF, DNI, or equivalent.
customer.document_numberDocument number without punctuation.
customer.billing_address.streetStreet name.
customer.billing_address.numberAddress number.
customer.billing_address.districtDistrict or neighbourhood.
customer.billing_address.cityCity.
customer.billing_address.stateState or province.
customer.billing_address.countryCountry code.
customer.billing_address.postal_codePostal or ZIP code.
additional_data.device.ip_addressCustomer's IP address.
additional_data.device.device_idDevice fingerprint session ID.
additional_data.device.finger_printFingerprint hash generated by the antifraud script.

Example of request

json
{ "idempotency_key": "4c3cbdc2-b41e-4e1c-b7fe-90ed10abd9bb", "request_id": "4802c01b-5aee-4962-a4f0-cff50439fda0", "order_id": "izgyekkmb8sd", "data": { "amount": 500, "currency": "EUR", "customer_id": "12345678Z", "payment": { "payment_id": "izgyekkmb8sd", "payment_method": "CREDIT", "transaction_type": "FULL", "number_installments": 1, "wallet": { "id": "103", "type": "10", "authorization_token": "<BASE64_ENCODED_APPLE_PAY_PAYMENT_TOKEN>" } }, "additional_data": { "customer": { "first_name": "Jose", "last_name": "da Silva", "phone_number": "+34911234567", "email": "customer@example.com", "document_number": "12345678Z", "document_type": "DNI", "billing_address": { "street": "Calle Mayor", "number": "10", "district": "Centro", "city": "Madrid", "state": "Madrid", "country": "ES", "postal_code": "28013", "complement": "N/A" } }, "device": { "ip_address": "192.0.2.1", "device_id": "{{$guid}}", "finger_print": "<DEVICE_FINGERPRINT>" } } } }

Example of response

json
{ "idempotency_key": "ae010d29-997f-4b8b-9890-32ab6c927a85", "seller_id": "7c966bb3-a8dc-4428-aa95-61081719ed80", "payment_id": "c7pk1y8j97o0", "order_id": "c7pk1y8j97o0", "amount": "500", "currency": "EUR", "status": "PENDING", "payment_method": "CREDIT", "received_at": "2026-02-23T15:16:37.589Z", "original_transaction_id": "", "authorized_at": "2026-02-23T15:16:38.853Z", "reason_code": "00", "reason_message": "Transaction is pending of EMV3DS authentication", "acquirer": "GETNET", "brand": "UNKNOWN", "additional_data": { "_links": [ { "rel": "3ds_html", "type": "POST", "href": "https://example.com/3ds/challenge", "creq": "<3DS_CREQ_VALUE>" } ] } }

SDWO Authorization Token flow

For SDWO Authorization Token transactions, the merchant sends the Base64-encoded Apple Pay payment token together with the SDWO fund transfer data.

information icon
Important: Only for SDWO Authorization Token transactions:
  • data.payment.wallet.id must be set to 103
  • data.payment.wallet.type must be set to 55
  • data.payment.wallet.tag must be set to AP

Example of SDWO Authorization Token request

json
{ "idempotency_key": "{{$guid}}", "request_id": "{{$guid}}", "order_id": "{{$guid}}", "link_id": "{{$guid}}", "data": { "amount": 1200, "currency": "BRL", "payment": { "payment_id": "{{$guid}}", "payment_method": "CREDIT", "save_card_data": false, "transaction_type": "FULL", "number_installments": 1, "dynamic_mcc": 6051, "wallet": { "type": "55", "id": "103", "tag": "AP", "authorization_token": "<BASE64_ENCODED_APPLE_PAY_PAYMENT_TOKEN>", "fund_transfer": { "pay_action": "FT", "receiver": { "account_number": "9999999999999995", "account_type": "00", "first_name": "Jane", "middle_name": "T", "last_name": "Smith", "addr_street": "1 Main ST", "addr_city": "SAO PAULO", "addr_state": "SP", "addr_country": "BRA", "addr_postal_code": "1408000", "nationality": "BRA", "phone": "5511977778888", "date_of_birth": "19901230", "id_type": "03", "id_num": "12345678900000" }, "sender": { "account_number": "9999999999999995", "account_type": "00", "first_name": "Jane", "middle_name": "T", "last_name": "Smith", "addr_street": "1 Main ST", "addr_city": "SAO PAULO", "addr_state": "SP", "addr_country": "BRA", "addr_postal_code": "1408000", "nationality": "BRA", "phone": "5511977778888", "date_of_birth": "19901230", "id_type": "03", "id_num": "12345678900000" } } } } } }

Example of SDWO Authorization Token response

json
{ "idempotency_key": "ff9c7c47-22f4-437b-af20-1f227a6bcaae", "seller_id": "a9c99f03-025c-4261-a9f5-de73ef593623", "payment_id": "21911ab4-85c7-4906-a56c-d75c5b7ea185", "order_id": "e478c15e-fd0a-40f4-8b70-48233ca203bd", "amount": "1200", "currency": "BRL", "status": "APPROVED", "payment_method": "CREDIT", "received_at": "2026-04-08T17:14:54.000Z", "transaction_id": "MCC00CVZ20408", "original_transaction_id": "MCC00CVZ20408", "authorized_at": "2026-04-08T17:14:55.283Z", "reason_code": "00", "reason_message": "captured", "acquirer": "GETNET", "soft_descriptor": "EC TESTES PAGONXT - NA", "brand": "MASTERCARD", "authorization_code": "446201", "acquirer_transaction_id": "000018185087" }

Comparison Table

Use the table below to identify which technical fields are required for each Apple Pay processing scenario.

ScenarioData handlingWhat merchant sends to GetnetCard objectTokenization objectAuthorization token3DS dataWallet fields
DAN card data flowMerchant / processor decrypts tokenDAN + expiryRequiredNoNoOptional or required by country/configurationid=103, type=10
DAN card data flow with 3DSMerchant / processor decrypts token and performs 3DSDAN + expiry + 3DS authentication fieldsRequiredNoNoRequiredid=103, type=10
Cryptogram card data flowMerchant / processor decrypts tokenized dataDAN + expiry + payment cryptogram + ECIRequiredRequiredNoUsually not requiredid=103, type=10
Authorization Token flowGetnet processes tokenBase64-encoded Apple Pay payment tokenNoNoRequiredHandled according to token content and configurationid=103, type=10
SDWO card data flowMerchant / processor decrypts tokenDAN or cryptogram card data + fund transfer dataRequiredDepends on scenarioNoOptional or required by configurationid=103, type=55
SDWO Authorization Token flowGetnet processes tokenBase64-encoded Apple Pay payment token + fund transfer dataNoNoRequiredDepends on token content and configurationid=103, type=55, tag=AP
information icon
Note: Device Account Number, payment cryptogram, and pkPaymentToken are Apple Pay payment data concepts. The scenarios above describe how payment data is sent to Getnet in the server-side payment request.

Additional resources