Apple Pay™

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 (Safari) or 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 an encrypted payment token (pkPaymentToken) containing the customer’s payment credentials or the card credentials stored in the customer’s Apple Wallet.
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.

• Include the Apple Pay Identity Guidelines within your websites
• Include the Apple Pay Identity Guidelines within your iOS app

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 Policy and Terms of Service.
• Your frontend environment must be served over HTTPS to initialize the Apple Pay SDK.
• Before going live, you must complete the domain verification and certificate setup in the Apple Developer Portal (see Step 2 below).
• 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 the Apple Pay API:

• Web integration (Safari): https://developer.apple.com/documentation/apple_pay_on_the_web

• iOS/macOS integration (PassKit): https://developer.apple.com/documentation/passkit/apple_pay

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

Step 2: Configure your Apple Pay account

Before moving to production, you must complete the following in the Apple Developer Portal:

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. Obtain the CSR: Log in to your Getnet Merchant Portal (or contact your account manager) to download the specific .csr file for Apple Pay.
   2. Apple Portal Upload: In the Apple Developer Portal, go to your Merchant ID settings, select Create Certificate under Payment Processing Certificate, and upload the Getnet .csr file.
   3. Download & Handover: Apple will generate a .cer file; download this and upload it back into the Getnet Merchant Portal to complete the handshake.
4. Merchant Identity Certificate — generate this to allow your server to authenticate with Apple’s servers during the payment session (Merchant Validation).

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

Step 3: Tokenize and process the payment

Once the customer authorizes the payment:

1. Apple Pay returns a payment token (pkPaymentToken) 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

Before the Apple Pay payment sheet appears, your frontend must perform a Merchant Validation step. The onvalidatemerchant event is triggered when the Apple Pay session starts. Your frontend forwards the validationURL to your backend, which then performs an authenticated POST to Apple’s servers using your Merchant Identity Certificate (mutual TLS).

Backend request to Apple

Your backend must POST to the validationURL received from the frontend with the following JSON body:

The TLS connection must present your Merchant Identity Certificate issued by Apple. Apple rejects calls that are not authenticated by this certificate.

Apple returns an opaque merchantSession object. Pass it back to the frontend unchanged.

Frontend handler

session.onvalidatemerchant = async (event) => {
  // POST event.validationURL to your backend.
  // The backend completes the mTLS handshake with Apple
  // and returns Apple's merchantSession object.
  const merchantSession = await callYourBackend(event.validationURL);
  session.completeMerchantValidation(merchantSession);
};

Backend example (Node.js)

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(); // opaque merchantSession object
}

Apple Pay authorization methods and Getnet processing models

Apple Pay supports card payments through two processing flows: a decrypted flow (DAN and CRYPTOGRAM) and an encrypted flow (Authorization Token).

Use the sections below to understand which Apple Pay authorization methods are supported and when to use Getnet’s Authorization Token flow.

How to choose your flow

Use the following criteria to pick a processing model:

If unsure, start with Authorization Token — it has the lightest PCI scope and works in both supported countries.

Decrypting the Apple Pay payment token

The DAN and CRYPTOGRAM flows require the merchant to decrypt the pkPaymentToken server-side before sending data to Getnet. Apple Pay never returns the raw card number or cryptogram in plaintext to the frontend.

Decryption uses the Payment Processing Certificate private key configured during onboarding (see Step 2). After decrypting, extract the following fields from the decrypted payload and map them to the Getnet payment request:

PCI scope: Decrypting the Apple Pay token brings the DAN into your environment, so the decryption service must operate within an appropriate PCI-DSS scope. If this is not feasible, use the Authorization Token (Encrypted) flow instead.

For the full decrypted token schema, refer to Apple’s Payment Token format reference.

DAN (Decrypted Flow)

DAN uses the Device Account Number — a tokenized representation of the card stored in the customer’s Apple Wallet. The transaction is processed similarly to a card-not-present payment.

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.

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.

CRYPTOGRAM (Decrypted Flow)

CRYPTOGRAM uses tokenized device card credentials and includes a TAVV cryptogram generated by the Apple device during the payment process.

This method provides stronger authentication evidence through the device-generated cryptogram. Because of this, additional 3D Secure authentication is generally not required, unless required by local regulation, issuer rules, merchant configuration, or transaction risk.

Authorization Token (Encrypted Flow)

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

Use this flow when your backend sends the encrypted pkPaymentToken to Getnet.

In this flow, extract the pkPaymentToken returned by Apple Pay, serialize it exactly as returned, encode it in hexadecimal, and send the encoded value in data.payment.wallet.authorization_token. Getnet uses this token to extract and process the payment data required for authorization.

Payment acceptance

For the best payment acceptance rates, Apple recommends supporting both decrypted and encrypted flows in your configuration. Supporting multiple methods allows Apple Pay to automatically choose the most secure and compatible option based on the customer’s device and card configuration.

Through the Getnet Regional API, merchants can process Apple Pay payments using multiple backend scenarios, including DAN, CRYPTOGRAM, Authorization Token, and SDWO-specific transactions.

You must define the payment capabilities you accept in merchantCapabilities, based on the methods implemented during your technical onboarding with Apple.

Cards

Cards available for the transaction.

You must define the card networks you accept in supportedNetworks, based on the networks implemented during your technical onboarding with Apple.

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

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

Billing address

Use requiredBillingContactFields to request billing address fields from Apple Pay when required for authorization, fraud prevention, AVS, or local compliance.

{
  "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 response object.

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

payment.token.paymentData

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 hexadecimal (not 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.

Encoding note: The tokenization.cryptogram field used in the CRYPTOGRAM flow is Base64-encoded as returned by the device. By contrast, the authorization_token field used in the Encrypted (Apple Token) flow must be hexadecimal-encoded. These encodings are not interchangeable.

Example of hex-encoding the pkPaymentToken in Node.js:

const hexToken = Buffer.from(JSON.stringify(pkPaymentToken)).toString('hex');

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

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

Integrate via Regional API

To integrate Apple Pay via the Regional 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 and CRYPTOGRAM, require the merchant to operate within the appropriate PCI-DSS scope for handling sensitive card data.
• HTTPS: Your frontend environment must be served over a secure connection to initialize the Apple Pay SDK.

Wallet field configuration

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

Characteristics

Available Features

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

Integration Flow

The lifecycle of an Apple Pay transaction begins with the frontend SDK obtaining a secure payload 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 requests a payment session from Apple’s servers (Merchant Validation).
3. Apple validates the merchant and returns a session object.
4. The Apple Pay sheet is displayed to the customer with their saved payment methods.
5. The customer selects a card and authorizes the payment via Face ID, Touch ID, or passcode.
6. Apple Pay generates and returns a payment token (pkPaymentToken) to the merchant.
7. The merchant sends the required Apple Pay payment data to Getnet.
8. Getnet prepares the transaction according to the selected processing scenario.
9. Getnet sends the authorization request to the card network or configured payment processor.
10. The processor returns the authorization result.
11. 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 the Apple Pay frontend and the selected Getnet processing scenario.

DAN

DAN is a card payment method within Apple Pay in which the transaction uses the Device Account Number — a tokenized representation of the user’s card linked to their Apple Wallet.

In this model, the card credentials are retrieved from the customer’s Apple Wallet. The DAN represents the primary identifier of the card within payment networks and is used to process the transaction through acquiring systems and card networks. This method follows a processing flow similar to traditional online card payments.

Example of request

{
  "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": "0258789",
    "payment": {
      "payment_id": "173f9e8d-4e0b-4503-8016-5cdafba89bee",
      "payment_method": "CREDIT",
      "transaction_type": "FULL",
      "number_installments": 1,
      "card": {
        "number": "4012001037141112",
        "expiration_month": "09",
        "expiration_year": "30"
      },
      "wallet": {
        "id": "103",
        "type": "10"
      }
    },
    "additional_data": {
      "customer": {
        "document_number": "77415914000148"
      }
    }
  }
}

Example of response

{
  "idempotency_key": "e61674fa-f50c-46e0-a7e4-3adb048d423f",
  "seller_id": "a9c99f03-025c-4261-a9f5-de73ef593623",
  "payment_id": "mkysz8d0llo8",
  "order_id": "mkysz8d0llo8",
  "amount": "500",
  "currency": "BRL",
  "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": "captured",
  "acquirer": "GETNET",
  "soft_descriptor": "EC TESTES PAGONXT - NA",
  "brand": "VISA",
  "authorization_code": "810172",
  "acquirer_transaction_id": "000454195865"
}

DAN with 3DS

For DAN transactions that require 3D Secure authentication (mandatory in Spain, optional in Brazil), 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.

Example of DAN with 3DS request (Spain)

{
  "idempotency_key": "63c7f8ee-51a6-470d-bb76-ef762b62bfb7",
  "request_id": "daac03dc-73db-453f-9bea-b1391669d5d3",
  "order_id": "ORDER-10187383",
  "data": {
    "amount": 500,
    "currency": "EUR",
    "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": {
        "document_number": "12345678Z",
        "document_type": "DNI"
      }
    }
  }
}

Example of DAN with 3DS response

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

Example of SDWO request

{
  "idempotency_key": "63c7f8ee-51a6-470d-bb76-ef762b62bfb7",
  "request_id": "daac03dc-73db-453f-9bea-b1391669d5d3",
  "order_id": "ORDER-10187383",
  "data": {
    "amount": 1200,
    "currency": "BRL",
    "customer_id": "0258789",
    "payment": {
      "payment_id": "173f9e8d-4e0b-4503-8016-5cdafba89bee",
      "payment_method": "CREDIT",
      "save_card_data": false,
      "transaction_type": "FULL",
      "number_installments": 1,
      "dynamic_mcc": 6051,
      "card": {
        "number": "4012001037141112",
        "expiration_month": "09",
        "expiration_year": "30"
      },
      "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"
          }
        }
      }
    },
    "additional_data": {
      "customer": {
        "document_number": "77415914000148"
      }
    }
  }
}

Example of SDWO response

{
  "idempotency_key": "e61674fa-f50c-46e0-a7e4-3adb048d423f",
  "seller_id": "a9c99f03-025c-4261-a9f5-de73ef593623",
  "payment_id": "mkysz8d0llo8",
  "order_id": "mkysz8d0llo8",
  "amount": "1200",
  "currency": "BRL",
  "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": "captured",
  "acquirer": "GETNET",
  "soft_descriptor": "EC TESTES PAGONXT - NA",
  "brand": "MASTERCARD",
  "authorization_code": "810172",
  "acquirer_transaction_id": "000454195865"
}

SDWO with 3DS Transactions

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

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

Example of SDWO with 3DS request

{
  "idempotency_key": "63c7f8ee-51a6-470d-bb76-ef762b62bfb7",
  "request_id": "daac03dc-73db-453f-9bea-b1391669d5d3",
  "order_id": "ORDER-10187383",
  "data": {
    "amount": 3000,
    "currency": "BRL",
    "customer_id": "test",
    "payment": {
      "payment_id": "173f9e8d-4e0b-4503-8016-5cdafba89bee",
      "payment_method": "CREDIT",
      "save_card_data": false,
      "transaction_type": "FULL",
      "number_installments": 1,
      "soft_descriptor": "APAY Test",
      "xid": "yFNXIadjt0mEsP5ob44vQPd0Zbg=",
      "ucaf": "B5kBAHNwQAAAAYdqmGESdiZwFVg=",
      "eci": "5",
      "tdsver": "2.3.1",
      "tdsdsxid": "9c2410c8-07c7-4e07-ac76-185e620970cf",
      "card": {
        "number": "4012001037141112",
        "expiration_month": "09",
        "expiration_year": "30"
      },
      "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"
          }
        }
      }
    },
    "additional_data": {
      "customer": {
        "document_number": "77415914000148"
      }
    }
  }
}

Example of SDWO with 3DS response

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.

{
  "idempotency_key": "ff9c7c47-22f4-437b-af20-1f227a6bcaae",
  "seller_id": "a9c99f03-025c-4261-a9f5-de73ef593623",
  "payment_id": "21911ab4-85c7-4906-a56c-d75c5b7ea185",
  "order_id": "ORDER-10187383",
  "amount": "3000",
  "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"
}

CRYPTOGRAM

CRYPTOGRAM is a card payment method within Apple Pay in which the transaction uses tokenized card credentials associated with a device and includes a security cryptogram (TAVV) generated during the payment process.

In this model, instead of the real card number, a Device Account Number (DAN) is used along with a TAVV cryptogram that proves the transaction was initiated from the user’s authenticated Apple device.

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

Example of request

{
  "idempotency_key": "f6e5cb13-a5fe-46f9-b467-29bd13c29e59",
  "request_id": "d808b53a-aa47-4484-8c99-cbe83624474c",
  "order_id": "izgyekkmb8sd",
  "data": {
    "amount": 500,
    "currency": "EUR",
    "customer_id": "02587894152",
    "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": "[email protected]",
        "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 response

{
  "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"
}

Authorization Token (Apple Token)

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

When a customer pays with Apple Pay, Apple returns an encrypted pkPaymentToken containing the customer’s 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 hexadecimal, and send the encoded value in data.payment.wallet.authorization_token.

Getnet uses the authorization_token to extract and process the payment data required for authorization.

The antifraud payload must also include the following fields.

Example of request

{
  "idempotency_key": "4c3cbdc2-b41e-4e1c-b7fe-90ed10abd9bb",
  "request_id": "4802c01b-5aee-4962-a4f0-cff50439fda0",
  "order_id": "izgyekkmb8sd",
  "data": {
    "amount": 500,
    "currency": "EUR",
    "customer_id": "02587894152",
    "payment": {
      "payment_id": "izgyekkmb8sd",
      "payment_method": "CREDIT",
      "transaction_type": "FULL",
      "number_installments": 1,
      "wallet": {
        "id": "103",
        "type": "10",
        "authorization_token": "<HEX_ENCODED_APPLE_PAY_PAYMENT_TOKEN>"
      }
    },
    "additional_data": {
      "customer": {
        "first_name": "Jose",
        "last_name": "da Silva",
        "phone_number": "+34911234567",
        "email": "[email protected]",
        "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

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

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

Example of SDWO Authorization Token request

{
  "idempotency_key": "4c3cbdc2-b41e-4e1c-b7fe-90ed10abd9bb",
  "request_id": "4802c01b-5aee-4962-a4f0-cff50439fda0",
  "order_id": "izgyekkmb8sd",
  "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": "<HEX_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

{
  "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.

Additional resources

• Apple Pay on the Web documentation
• Apple Pay Web integration checklist
• Apple Pay iOS/macOS documentation
• Apple Pay Identity Guidelines
• Authentication for token management.
• Publish your integration