--- title: "Click to Pay" slug: "click2pay-integration-guide" updated: 2026-07-08T19:33:55Z published: 2026-07-08T19:33:55Z canonical: "www.documentation.paynetics.digital/click2pay-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. # Click to Pay ## Overview This document covers the functionalities and constraints of the Click to Pay enablement for the Paynetics Acquiring product. It provides comprehensive information on how to integrate and operate it. ## Product Description Click to Pay is a network-based digital wallet service that allows customers to store and use their card credentials securely for online transactions. **Scope:** - Click to Pay integration with Visa and Mastercard. - Secure Customer Authentication (SCA) compliance. **Out of Scope:** - Non-card-based digital wallets. - PayPal or alternative e-wallet services. Click to Pay is a card scheme-supported digital wallet that streamlines online payments. Users can enroll their card details once and use them across multiple merchants without re-entering information. The service supports both one-click and multi-factor authentication-based transactions. ## 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 Paynetics. The supported countries are EU27, Iceland, Liechtenstein, Norway, or the UK. ## Merchant Onboarding There are no additional onboarding requirements for merchants using Click to Pay and Network Tokenization beyond the standard Paynetics onboarding process: 1. **Automated Merchant Onboarding** – Merchants can onboard through the Paynetics onboarding API. 2. **Manual Onboarding** – For cases where automation is not feasible, manual setup is required. Merchants need to submit onboarding documents via a secure shared portal and notify Paynetics at underwriting@paynetics.digital. Once approved, merchants can start accepting Click to Pay and Tokenized payments. *Note: Paynetics does not manage cardholder Click to Pay enrollment; this is handled by Visa/Mastercard.* ### 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. ## 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 Click to 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: - click-to-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 | Yes | | **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": "click-to-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:** Required if the card has not been authenticated already. **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 for Visa; Required for Mastercard only if the card has not been authenticated already | | **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.** 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. Strong Customer Authentication. A regulatory requirement under PSD2 mandating that electronic payments are authenticated using at least two independent factors: something the user knows, something the user has, and something the user is. SCA is enforced at checkout via 3DS for card payments. 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. **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 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.