--- title: "Apple Pay and Google Pay" slug: "apple-pay-and-google-pay-integration-guide" updated: 2026-07-09T15:09:26Z published: 2026-07-09T15:09:26Z canonical: "www.documentation.paynetics.digital/apple-pay-and-google-pay-integration-guide" --- > ## Documentation Index > Fetch the complete documentation index at: https://www.documentation.paynetics.digital/llms.txt > Use this file to discover all available pages before exploring further. # Apple Pay and Google Pay ## Overview This document covers the functionalities and constraints of the Apple Pay and Google Pay enablement for the Paynetics Acquiring product. It provides comprehensive information on how to integrate and operate it. ## Product Description **Overview:** As part of Paynetics' commitment to offering innovative, secure, and convenient payment solutions, Paynetics provides **Apple Pay** and **Google Pay** integration for your merchants. These mobile wallets offer a consistent and secure way for customers to make payments using their smartphones, tablets, or wearables – eliminating the need for physical cards and enhancing the overall customer experience. Both **Apple Pay** and **Google Pay** are designed for easy integration with existing payment systems, allowing merchants to accept payments across a variety of digital channels, including in-app, online, and in-store. With their robust security features, these mobile wallets ensure that customer data is encrypted and tokenized, minimizing the risk of fraud. ## Currency and country coverage The supported settlement currencies are **EUR, GBP, and BGN.** Important note is that the currencies that you will choose. The processing currencies are all currencies supported by ApplePay and GooglePay. The supported countries are EU27, Iceland, Liechtenstein, Norway, or the UK. ## Merchant Onboarding No specific onboarding requirements for the merchants processing Digital Payments. The process is the same as our current process with PSPs/ISOs which is as follows: 1. Automated merchant onboarding and setup – Paynetics onboarding API will be used. 2. Manual Onboarding – the merchants are set manually in the Paynetics system and payment processor’s system. The merchant’s onboarding is confirmed individually with each client before starting the partnership. The merchant onboarding with GooglePay and ApplePay is a responsibility of the partner. Paynetics is responsible for processing of the transactions, yet not for the decryption of the meages or exchanging keys. ### Onboarding via API The recommended way of onboarding merchants is via API. For more information on the process During application processing, Paynetics may contact you or the merchant to request more information. ### Manual onboarding To onboard merchants manually you will be provided with dedicated access to a secure shared storage where you must upload the filled in merchant application form together with the required documents. You must notify us by email to underwriting@paynetics.digital for your form to be reviewed. manual onboarding has limited capacity, and it’s not recommended. Paynetics can only process 10-15 applications a month under the manual flow. Once your application is approved, your merchant will be registered in the Paynetics system, and a funding account will be opened. The details about the merchant that you will need for initiating OCTs will be received in the ticket. ## Fees set-up The fees setup follows the current procedure with no specifics. ## Payouts The payouts follow the current procedure with no specifics. ## Reporting and reconciliation You can track all transactions via API real-time. In the end of the day, a reconciliation report is sent with all transactions from the previous day via SFTP. ## Profit share Your profit share is included in the acquiring monthly commission report file. The file is sent up to the 10th day of the month. Upon your approval of the commission file, you must send us an invoice. The invoice will be duly paid as per our contractual agreement terms. ## Technical Integration Once you have signed agreement for acquiring services you will be provided with access to your Sandbox instance where you can carry on the integration. Once you have integrated the solution, you will run a set of tests validated by Paynetics and you will be ready to move to production. Migrating to production is a matter of receiving and configuring a new API key and changing the API root path. **Execute Apple/Google Pay payment** To execute a payment, use the POST /v1/purchase or POST/v1/pre-authorization endpoint. No difference in the request parameters sent in the Purchase and Pre-authorization. The Pre-authorization request must always be followed up by capture request POST/v1/capture, otherwise the transaction will not be cleared. **Specific Request Parameters** | **card_number** | The network card token provided by token requestor | | --- | --- | | Data Type | String, length 16 | | Required | Yes | | **card_expiration_month** | The month on which the network token expires | | Data Type | String, “01” to “12” | | Required | Yes | | **card_expiration_year** | The year on which the network token expires | | Data Type | String, min current year | | Required | Yes | | **cardholder_name** | The name of the cardholder | | Data Type | String, max 27 chars | | Required | Yes | | **wallet_identifier** | The parameter supports the transmission of Wallet Identifiers used by the card schemes. Supported values are: - apple-pay - google-pay | | Data Type | String (values from nomenclature) | | Required | Yes | | **digital_payment_cryptogram** | The parameter supports: - DSRP Cryptogram – as per Mastercard CIS DE 104 Subelement 001 - Token Authentication Verification Value TAVV - cryptogram data as per Visa VIP Field 126.8 | | Data Type | String | | Required | Required for CIT (cardholder-initiated transaction); Optional for MIT (merchant-initiated transaction). | | **remote_commerce_acceptor_identifier** | The parameter carries a unique identifier agreed by the Merchant with wallet providers. | | Data Type | String | | Required | Not Applicable for Visa; Optional Mastercard: recommended for higher approval rates; contains a merchant identifier such as the merchant business website URL or reverse domain name as presented to the consumer during checkout. The merchant identifier is provided encoded as Base64. | **Request:** **Example Request** ```json {     "reference": "dsds",     "merchant": "7cb0db766c86cdda3939871adfece952",     "amount": 1,     "currency": "EUR",     "card_number": "4111111111111111",     "card_expiration_month": "11",     "card_expiration_year": "25",     "cardholder_name": "XXXXXX",     "wallet_payment": {         "wallet_identifier": "google-pay",         "digital_payment_cryptogram": "stringstringstringstringstri",         "remote_commerce_acceptor_identifier": "string "     } } ``` **Response:** **Example Response** ```json {   "code": 0,   "data": {     "card_number": "411111XXXXXX1111",     "processing_code": "000000",     "amount": 1,     "stan": "180801",     "local_time": "145916",     "local_date": "0813",     "auth_code": "361156",     "response_code": "00",     "card_acceptor_terminal_id": "16P17777",     "card_acceptor_identification_code": "1602071111",     "currency": "978",     "transaction": "9310bc2b-171b-47f7-8d2b-d97cdfa546d1",     "cvv_status": " 06",     "ccti_id": "80",     "transaction_stamp": "0000007761232611201A",     "card": "39da5b38-15f3-4371-8a9b-09f138437b4e",     "original_network_response_code": "00"   } } ``` **3D secured transactions** **Mastercard:** Not required. **Visa:** Optional. If the merchant has not obtained ECI 05 from the Token Requestor when the cryptogram was retrieved, it might be beneficial to perform a 3D Secure (3DS) authentication to obtain ECI 05. The ECI value is what determines where the liability stays in a transaction. With ECI 07 returned the liability remains with the merchant, and with ECI 05 the liability shifts to the issuer. **3D Secure Request Parameters** | **cavv** | The Parameter supports: - Cardholder Authentication Verification Value (CAVV) - applicable for Visa acceptance - UCAF (Universal Cardholder Authentication Field), applicable for Mastercard or Maestro acceptance | | --- | --- | | Data Type | String | | Required | Yes | | **eci** | The parameter supports the Electronic Commerce Indicator (ECI) which indicates the level of security applied. Supported values: **Visa** - **05:** 3DS authentication successful; transaction is secured by 3DS. - **06:** authentication was attempted but was not or could not be completed. - **07**: 3DS authentication either failed or could not be attempted. **Mastercard** - **02:** 3DS authentication successful; transaction is secured by 3DS. - **01:** 3DS authentication was attempted but was not or could not be completed. - **00:** 3DS authentication is either failed or could not be attempted. | | Data Type | String, maxLength: 2 | | Required | Yes | | **Version** | 3D Secure Version Number | | Data Type | Integer, value=2 | | Required | Optional | | **directory_transaction_id** | 3D Secure Directory Server Transaction ID delivered during the 3D Secure 2.0 authentication process by the directory server | | Data Type | String | | Required | Yes, if 3D Secure Version Number has been initiated. | **Request:** ```json {     "reference": "dsds",     "merchant": "7cb0db766c86cdda3939871adfece952",     "amount": 1,     "currency": "EUR",     "card_number": "4111111111111111",     "card_expiration_month": "11",     "card_expiration_year": "25",     "cardholder_name": "XXXXXX",     "cavv": "AJkCCReZIncEQFcQBZkiAAAAAAA=",     "eci": "05",     "version": 2     "directory_transaction_id": "7b03c772-dba0-4818-872e-849d63a5a659",     "wallet_payment": {         "wallet_identifier": "google-pay",         "digital_payment_cryptogram": " stringstringstringstringstri",         "remote_commerce_acceptor_identifier": "string"     } } ``` **Response:** **Example Response** ```json {   "code": 0,   "data": {     "card_number": "411111XXXXXX1111",     "processing_code": "000000",     "amount": 1,     "stan": "180801",     "local_time": "145916",     "local_date": "0813",     "auth_code": "361156",     "response_code": "00",     "card_acceptor_terminal_id": "16P17777",     "card_acceptor_identification_code": "1602071111",     "currency": "978",     "transaction": "9310bc2b-171b-47f7-8d2b-d97cdfa546d1",     "cvv_status": "06",     "ccti_id": "80",     "transaction_stamp": "0000007761232611201A",     "card": "39da5b38-15f3-4371-8a9b-09f138437b4e",     "original_network_response_code": "00"   } } ``` **Note:** The integration guide is applicable to all merchants integrated with Paynetics Acquiring API. **The guide is not applicable to merchants integrated with ACI Gateway.** Apple's contactless and in-app payment service that enables cardholders to pay using iPhone, iPad, Apple Watch, or Mac. Cards are stored as device-specific network tokens rather than the underlying PAN, so the physical card number is never transmitted at the point of sale. The business of processing card payments on behalf of merchants. An acquirer receives authorisation requests from merchants, forwards them to the issuing bank, and settles funds to the merchant. Paynetics also operates as an acquirer for approved merchant categories. **Tokens** are unique identifiers used throughout the Paynetics platform to securely reference objects. Tokens exist for instances, programs, accounts, balances, cards, merchants, and transactions. They are mandatory in API calls and ensure secure identification without exposing sensitive data, accurate routing of operations, and consistent handling across services. For example, a balance token specifies which funds are debited or credited, a card token identifies the card used in a transaction, and a merchant token links activity to a specific merchant. A **Merchant** represents a business entity that accepts payments or uses acquiring-related services. Merchants are created within an instance and can be associated with one or more accounts, including funding and settlement accounts. Merchant configuration is subject to underwriting and card scheme approvals, depending on the services enabled. Merchants become operational through **merchant onboarding**, once the relevant application has been approved. A cardholder authentication protocol used during online card payments. 3DS reduces card-not-present fraud and supports regulatory requirements including Strong Customer Authentication. Authentication can be frictionless (no user interaction required) or challenge-based (the user must actively verify the transaction). The person to whom a Card is issued. The cardholder is responsible for all transactions made with the card in accordance with agreed terms.