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 our commitment to offering innovative, secure, and convenient payment solutions, we are now providing Apple Pay and Google Pay integration for your merchants. These mobile wallets offer a seamless 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, we may contact you or the merchant to request more information.

Manual onboarding

To onboard merchants manually we will provide you 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 from to be reviewed.

Please be aware that 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, we will be sending you a reconciliation report with all transactions from the previous day via SFTP.

Profit share

We will be adding your share of the profit in the acquiring monthly commission report file. The file is sent up to the 10^th day of the moth. 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

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

The execute a 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

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

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

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

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