# Platform {#en_platform_about} A section with the general information about the payment platform, its structure, and operation. This section contains general information about working with the Ecommpay payment platform. Use it to understand the fundamentals of how the platform works and how to establish the interaction with the platform via one or several interfaces.For example, if you need to accept payments with the use of the payment form by Ecommpay, issue refunds via an API, and have your employees monitor information via an online dashboard panel, you can use this section to learn about interfaces and components that fit the needs of your company, general steps of integration with the platform, workflows of specific payment types and their statuses, data signing, and different ways to check payment information. Based on the information you have learned, you can set up the most fitting solutions for your business. This section includes the following information: - [Overview](en_platform_overview.md)—an introductory article with the information about the payment platform, its interfaces, components and key capabilities. - [Integration](en_platform_registration.md)—articles about the general procedure of integrating with the platform and the specialised solutions for specific categories of merchants. - [Payment processing](en_platform_payment_model.md)—articles about payment types that can be processed via the platform, workflows and possible statuses of these payments and operations performed within them. - [Signature generation and verification](en_platform_signature.md#)—information about data signing and verification required in order to work with any of the program interfaces of the platform. - [Handling payment processing information](en_platform_payment_information.md)—information about receiving and processing data on payments executed via the platform so that the merchant can analyse, monitor, and respond to payment processing activity. In addition to the information covered in this section, in order to learn about the platform's capabilities and interacting with it, you can use the articles about working with specific interfaces and components of the platform in the **Tools** section, information [on risk management](en_dbl_risks.md#)and [chargebacks](en_faq_chargebacks.md), answers to [FAQs](en_faq.md), and other articles of this documentation portal. Along with that, if you have any questions, you can contact your Ecommpay account manager and the technical support. - **[Overview](en_platform_overview.md)** An article with the introductory information about the payment platform, its interfaces, components, and key capabilities. - **[Integration](en_platform_registration.md)** Articles about the general procedure of integrating with the platform and the specialised solutions for specific categories of merchants. - **[Payment processing](en_platform_payment_model.md)** Articles about payment types that can be processed via the platform, workflows and possible statuses of these payments and operations performed within them. - **[Signature generation and verification](en_platform_signature.md#)** An article about signing data in API requests, responses, and callbacks and verifying signatures in order to ensure secure data exchange with the payment platform. - **[Handling payment processing information](en_platform_payment_information.md)** Articles about receiving and processing data about payments executed via the platform in order to analyse, monitor, and respond to payment processing activity. --- # Overview {#en_platform_overview} An article with the introductory information about the payment platform, its interfaces, components, and key capabilities. ## Introduction {#section_cb3_crm_vzb .section} The Ecommpay payment platform allows you to processdifferent types of paymentsalmost everywhere in the world with support for a wide range ofcurrencies,payment methods, and payment scenarios. It relies on exceptionally thought out and organised processes and high-performance computing resources, which, from the technical standpoint, makes the platform an advanced information system—state of art, high-integrity, and efficient. Thanks to this, all required actions in the platform are executed in milliseconds while merchants and their customers can expand ranges of services they offer and enjoy high quality performance of the platform. ![](images/ecommpay/en_platform_functional.svg "Processing payments via main interfaces of the platform") At the same time, the scalability of the Ecommpay payment platform, with its plethora of capabilities and use options, leads to a wide range of ways of how merchants can work with it. This makes the interaction with the platform convenient and efficient, but it can also be challenging, for example, when the merchant needs to find the most optimal solution that fits the merchant's business needs.To make sure that your questions about working with the platform are answered, you can use this documentation portal\(including the documentation survey on the home page\). You can also contact your account manager and the technical support. ## Key concepts: projects and payments {#section_dlt_rc1_xzb .section} While the integration workflows and scenarios can vary, working with the platform starts with registering in it a specific merchant and a project of interaction between the merchant's web service and the platform. Along with that, the project is assigned a permanent identifier, and a wide range of customisable properties is set up for it. These properties include support for payment methods and currencies, as well as various parameters that determine payment processing workflows and procedures. Once this has been done \(and only then\), it is possible to process payments in the project of the merchant, with payments defined as compound actions performed to carry out transfers of funds between merchants and their customers. The number of projects set up for one merchant can vary. Most often, one project is enough, but in certain cases, the number of projects can increase. As a rule, the optimal number of projects is determined by the Ecommpay specialists on the basis of the merchant's business specifics and goals. More importantly, this number can be changed in the course of collaboration with Ecommpay. As for payments, they can include a different number of operations that have to do with the transfer of funds.For example, within one payment, first a purchase takes place, and then—a full or partial refund. As another example, a series of regularly recurring debit operations for a fixed amount is processed within one subscription payment. And so on. Available payment types, operations, and their statuses are strictly defined in the platform and are described in this section. Meanwhile, as you read, it is important to keep in mind that payments are processed within projects and can include a varying number of operations. Overall, this logic—that to work with the platform, the merchant's project needs to be registered and that within these registered projects payments are processed and include a certain number of operations—can be considered the basis for understanding the interaction with the platform.It applies to all actions in the Ecommpay platform starting from test integrations and processing test payments and ending with distributing permissions for accessing information about individual payments and operations by individual projects. ## Tools: interfaces and components {#section_itw_sg1_xzb .section} To work with the Ecommpay payment platform, you and your web service can use specialised interfaceseach of which allows you to achieve specific business goals. These interfaces include: - [Payment Page](en_PP_about.md)—the payment form developed by Ecommpay that is invoked via an API and allows you to process purchasesand perform other actionswith the use of various payment methods. - [Gate](en_Gate_Integration_About.md)—the payment API that provides you with the largest range of capabilities for working with paymentsof all supported typesand payment methods and implies that your web service utilises in-house UI solutions. - [Dashboard](en_dbl_about.md)—the web interface for your employees that allows them to configure projects,including the interface of Payment Page, and to monitor the state of all payments\(processed and in-progress\), to manage their execution, and to initiate various payments and operations. - [Data API](en_dbl_api_protocol.md)—an API that allows you to retrieve information about operations, chargebacks, and balances for the projects in use. It also helps you establish the workflow of monitoring and analysing payment processing outside of Dashboard\(for example, in the external BI system\). At the same time, for more convenient ways of working with the platform, you can also use additional components—self-contained software products that can be implemented in the web service to achieve specific goals.These components include: - [SDKs for mobile applications](en_sdk_overview.md)—software development kits \(SDKs\) to integrate Android and iOS applications with the Ecommpay payment platform.Merchants can use a special version of Payment Page or their own user interface. - [Integration modules for CMS](en_CMS.md)—plug-ins\(certain systems refer to them as *cartridges*\) that help connect the merchant's web service created in a popular CMS system or a specialised ecommerce platform to the Ecommpay platform. - [SDKs for data signing](en_sdk_overview.md#section_vcj_5zv_tvb)—language-specific specialised software development kits \(SDKs\) that facilitate signing data sent in requests and verifying data integrity in responses and callbacksin the API interaction with the platform. Together these interfaces and components serve as tools that allow merchants to work with the platform. In different cases, this work can be organised with the use of a different number of tools.Thus, sometimes a task can be completed by using one interface \(Dashboard\), and in other cases, using SDKs formobile applications anddata signing,Payment Page, Gate, Dashboard, and the Data API can be more effective. As a rule, the key factors affecting the choice of this or that tool include payment types and user scenarios, web service development methods, and the preferred ways to organise work with the platform. These factors, for example, are taken into account in the responses that are given as a result of taking our survey available on the home page. Similarly, when the Ecommpay specialists help you find the most optimal solutions for your business, these factors are taken into consideration as well. ## Capabilities and procedures {#section_m2q_l22_xzb .section} Capabilities of the Ecommpay platform are diverse and, more importantly, are supported to a varying degree with different tools.Thus, Payment Page allows you to initiate authorisation holds as part of performing two-step purchases, but to withdraw or release the held funds you need to use Gate or Dashboard \(or set up automatic *capture* operations after a specific time lag\). This is true about each tool and, therefore, it is important to keep in mind that: - Each tool of the platform is intended for achieving its own specific set of goals. - Achieving any applicable goal can be accomplished with the use one or several tools. - To ensure efficient use of platform, it is often beneficial to combine its capabilities and tools according to the specifics of goals you are working to accomplish. It can also be added that from the technical standpoint supporting any capability implies performing certain procedures, and for different tools these procedures, this way or another, will have to do with the configuration of the web service, the customers, or employees of the merchant. For example, the 3‑D Secure authentication of the customer used in purchase processing does not require active participation of the web service when processing involves payment interfaces of Ecommpay \(only customer actions are required\). However, when processing occurs via Gate, the web service is required to perform a whole number of actions \(accepting and processing data and redirecting the customer\). These aspects of using different tools and capabilities are worth keeping in mind. The capabilities of the platform can be divided into several groups functionality-wise: - Processing paymentsof different types\(or performing essential payment procedures\)—a group of capabilities that ensure basic functions of the platform. These capabilities allow processing purchasesof different types\(in one or two steps, one time or with different kinds of repetition\), payouts, and 'nominal' payments for verifying payment instrumentswith the use of various payment methods. - Performing auxiliary payment procedures—a group of capabilities that ensure compliance with the requirements imposed on payment processing in specific cases. These capabilities allow executing procedures that are not always required but mandatory in certain cases and situations due to the requirements imposed by payment systems, regional specifics, or other conditions.As a rule, these procedures include additional customer verification, 3‑D Secure and AVS checks being the prime example. - Expanding the scope of payment scenarios\(or using additional capabilities\)—a group of capabilities that ensure flexible configuring of the integration for specific situations and business needs to improve payment services. These capabilities allow performing procedures that can be considered complementary enhancements: they are not required to process payments, but they facilitate the variability of payment scenarios, boost payment interfaces conversion and payment acceptance rates,strengthen fraud preventionand increase customer loyalty. - Managing payment solutions—a group of capabilities that allow merchants to manage payment solutions but do not affect payment processing per se. These capabilities are intended for simplifying the use of procedures for monitoring and analysing payment information,handling chargebacks, managing balances and other processes important for maintaining merchants' business operations. Together, these groups of capabilities ensure full functionality and scalability of the platform for merchants. **Parent topic:**[Platform](en_platform_about.md) --- # Integration {#en_platform_registration} Articles about the general procedure of integrating with the platform and the specialised solutions for specific categories of merchants. Integration with the Ecommpay payment platform requires solving a number of organisational, legal, and technical issues. To ensure efficiency of the integration process, Ecommpay constantly develops different solutions, both for general use and specialised. - [General procedure](en_platform_registration_workflow.md)—an individualised approach to integration; the specialists of Ecommpay are in constant communication with the representatives of the merchant to ensure all questions are solved quickly and efficiently. It is used for mid-market and large enterprises that meet the requirements of Ecommpay to their clients. - [Ecommpay for Small Businesses](en_platform_onboarding_for_small_businesses.md#)—a partially automated approach; includes self-service onboarding of the merchant and the subsequent technical integration without the involvement of an account manager assigned by Ecommpay. It is used for small businesses in the UK that meet the eligibility criteria of Ecommpay. - **[General procedure](en_platform_registration_workflow.md)** An article about the general procedure of integrating with the platform used for mid-market and large enterprises that meet the requirements of Ecommpay to their clients. - **[Onboarding via Ecommpay for Small Businesses in the UK](en_platform_onboarding_for_small_businesses.md#)** An article about a specialised procedure of integrating with the platform used for small businesses in the UK that meet the eligibility criteria of Ecommpay. **Parent topic:**[Platform](en_platform_about.md) --- # General procedure {#en_platform_registration_workflow} An article about the general procedure of integrating with the platform used for mid-market and large enterprises that meet the requirements of Ecommpay to their clients. Depending on the tools that will be used for working with the platform, the actual steps and the order in which they should be taken are going to varysignificantly. In general case, you need: 1. Address the following organisational issues of interaction with Ecommpay: 1. If your company is not yet a client of Ecommpay and has not obtained the project identifier and a secret key for interacting with the platform, submit [an application](https://ecommpay.com/apply-now/).Once the application receives its initial approval, you will have the contact information of the Ecommpay specialists in charge of your onboarding. 2. For processing payments made with Visa and Mastercard, provide your Ecommpay account manager with the documents of compliance with [the PCI DSS requirements](en_faq_integration.md#fig_fgk_rgs_4nb). The following documents are required: - From all merchants—[the ASV scan](en_glossary.md#) report. ASV scanning must be performed by the authorised scanning service providers \(PCI SSC Approved Scanning Vendor, ASV\) quarterly and after every significant change in the network infrastructure.The Ecommpay merchants can select these providers on their own and, if relevant, involve a provider that is in partnership with Ecommpay. To have the scanning services via the partner arranged, contact your account manager. - From the merchants processing over 6 million operations annually \(Level 1\)—the Attestation of Compliance, AOC. - From the merchants processing up to 6 million operations annually \(Levels 2, 3, and 4\)—[the Self-Assessment Questionnaire](https://www.pcisecuritystandards.org/pci_security/completing_self_assessment), SAQ. With questions on completing the questionnaire, contact your Ecommpay account manager. 3. Coordinate the procedures of integrating with the payment platform, testing\(including testing card payments and some alternative payment methods\), and launching the functionality with the Ecommpay technical support specialists. 2. Complete preliminary technical tasksby using either your in-house resources or the specialised components offered by Ecommpay if needed.Make sure to implement signature generation and callback response processing on the server side of the web service. 3. Test the required actions and launch the integration solution in coordination with the Ecommpay technical support. Upon testing and monitoring, when the required actions are performed correctly, the Ecommpay technical support specialists will switch to interacting with the web service in the full-time support mode. **Parent topic:**[Integration](en_platform_registration.md) --- # Payment processing {#en_platform_payment_model} Articles about payment types that can be processed via the platform, workflows and possible statuses of these payments and operations performed within them. The Ecommpay payment platform allows you touse various payment methods to process different paymentsmade with payment cards and other payment instruments. All payments, regardless of payment method, are separated into several basic types. - One-time purchase with [one step](en_platform_sms_model.md) and [two steps](en_platform_dms_model.md)—`purchase`; - COF purchase with [on-demand](en_platform_recurring_model.md) or [automatic](en_platform_sheduled_recurring_model.md) debiting of funds—`recurring`; - [Payment link purchase](en_platform_invoice_model.md) with one step and two steps—`invoice`; - [Payout](en_platform_payout_model.md)—`payout`; - [Payment instrument verification](en_platform_account_verification_model.md)—`account verification`. This subsection covers information aboutthe general payment model and models of separate payment types. - **[Payment model](en_platform_payment_model_overview.md)** An article about the general model of initiating and processing payments via the platform. - **[One-time one-step purchase](en_platform_sms_model.md)** An article about processing one-time purchases with immediate debiting of funds \(one step\), includes the description of the processing workflow, possible statuses and operations. - **[One-time two-step purchase](en_platform_dms_model.md)** An article about processing one-time purchases with placing an authorisation hold and subsequent debiting of funds \(two steps\), includes the description of the processing workflow, possible statuses and operations. - **[On-demand COF purchase](en_platform_recurring_model.md)** An article about processing recurring purchases with debiting of funds initiated by the merchant \(unscheduled\), includes the description of the processing workflow, possible statuses and operations. - **[COF purchase with automatic debiting](en_platform_sheduled_recurring_model.md)** An article about processing recurring purchases with automatic debiting of funds \(according to a set schedule\), includes the description of the processing workflow, possible statuses and operations. - **[Payment link purchase](en_platform_invoice_model.md)** An article about processing purchases with the use of payment links, includes the description of the processing workflow, possible statuses and operations. - **[Payout](en_platform_payout_model.md)** An article about processing payouts, includes the description of the processing workflow, possible statuses and operations. - **[Payment instrument verification](en_platform_account_verification_model.md)** An article about verifying a payment instrument \(by debiting a zero amount\), includes the description of the processing workflow, possible statuses and operations. **Parent topic:**[Platform](en_platform_about.md) --- # Payment model {#en_platform_payment_model_overview} An article about the general model of initiating and processing payments via the platform. The Ecommpay payment platform is used for processing *payments*. A payment in the payment platform is a set of tasks to transfer funds between the merchant and their customer.It can be a transfer of funds from the customer to the merchant \(*purchase*\), or from the merchant to the customer \(*payout*\). Refunds are processed within the purchase and, therefore, are not considered a separate payment type. However, payments also include *payment instrument verification* that can involve transferring a zero amountor placing a hold on the customer account for a specified amount and subsequent cancellation of this holding. There are several ways to initialise a payment. You can send an *HTTP request* by using the Gate API or the Payment Page APIor perform certain actions in the Dashboard interface. Besides, payments can be initiated with the use of other tools for working with the payment platform. If a request to perform a payment is successfully accepted for processing, in the payment platform the `payment` object and the first \(or the only one\) `operation` object associated with this payment are created. ![](images/payment%20model/en_gate_payment_model_1.svg) When the payment takes more that one operation, normally the merchant needs to send the request for initiating each subsequent operation. However, in some cases, the payment platform automatically initiates the subsequent operation, for example, automatic debit operations performed as part of a COF purchase. General information about processing payments via the Ecommpay payment platform is provided in the [Payment processing](en_platform_payment_model.md) section, while technical information is provided in the sections with information about the platform's interfaces. **Parent topic:**[Payment processing](en_platform_payment_model.md) --- # One-timeone-step purchase {#en_platform_sms_model} An article about processing one-time purchases with immediate debiting of funds \(one step\), includes the description of the processing workflow, possible statuses and operations. ## Overview {#section_zvh_1rr_whb .section} *One-time one-step purchase* is a payment type which uses only one request to make a one-time transfer of funds from customer to merchant. This is the most basic purchase type in which the customercard or account is immediately debited for the amount of the purchase, for example to pay for an item of goods. ## Payment model {#section_ajd_brr_whb .section} To initiate one-step purchase, a request of the `sale` category should be sent to the platform or the payment form should be opened in the Purchase mode with the `sale` payment type specified. Once the payment platform receives the request, it creates the `sale` operation which eventually results in debiting the customercard or account. A one-step purchase may require the merchant to send the following additional requests: - *Customer authentication by using the 3‑D Secure technology*.In case of working via Gate, for such authentication, the web service is required to accept the corresponding callback and perform the needed actions, while in case of working via Payment Page, all actions needed for authentication are carried out without the web service involved. - *Customer authentication performed by the payment system on merchant's request*. In case of working via Gate, for such authentication, the web service is required to accept the corresponding callback and perform the needed actions, while in case of working via Payment Page, all actions needed for authentication are carried out without the web service involved. - *Submission of additional payment information* for any party involved in the payment processing.In case of working via Gate, for submitting additional information, the web service is required to accept the corresponding callback and send a request with the needed data, while in case of working via Payment Page, all actions needed for that are carried out without the web service involved. If the payment method supports the capability of confirming that the funds were transferred to the payment recipient, then, after the `sale` operation has been completed, the `payment confirmation` operation is initiated in the payment platform. It results in receiving such a confirmation from the provider. If the payment method supports refunds, after completing a one-time one-step purchase you can return your customers their money if needed. This can be done as a result of a [request](en_Gate_Refund.md) sent via Gate or as a result of the corresponding [action](en_dbl_payments.md#) in the tab of the needed purchase in the Dashboard interface. For a refundwithin a card payment, depending on the refund time and amount and the payment instrument used for the payment, one of the following operations is initiated: - `reversal` if the refund is initiated within the [operation day](en_glossary.md#) regardless of the purchase amount for a Mastercard card and provided that the total purchase amount is refunded for a card of any other card network; - `refund` if the refund is initiated for a card of any card network after [operation day](en_glossary.md#) and regardless of the amount and within the operation day provided that a partial purchase amount is refunded for a card of all card networks except Mastercard. In case of a refund for a purchase processed with the use of an alternative payment method, normally the `refund` operation is initiated. The `reversal` operation can be initiated when the purchase is assigned the `success` status following the confirmation from the payment system or the provider, but the funds cannot be transferred to the payment recipient. ![](images/payment%20model/en_payment_model_2.svg "State diagram for one-time one-step purchase") The rest of this section describes any possible statuses of a one-time one-step purchase and operations related with the purchase. More information about processing one-time one-step purchasesusing payment cards is provided in the[Payment Page](en_PP_about.md) and [Gate](en_Gate_Integration_About.md) sections, while the information about processing purchases with the use of other payment instruments is provided in the [Payment methods](en_pm_about.md) section. ## Payment statuses {#section_n4r_brr_whb .section} The following table describes the statuses of a one-time one-step purchase. |`error`|Error occurred when request processing. Payment is not performed.|*Final status. The request can be resent with the same payment identifier and the same payment can be retried.*| |`processing`|Payment is being processed.|*Intermediate status*| |`awaiting 3ds result`|Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received within the required timeout time, then the payment status is set to `decline`. Normally, the timeout is 30 minutes, but it may differ depending on a provider. For more information about specific timeouts, contact technical support at [support@ecommpay.com](mailto:support@ecommpay.com).|*Intermediate status*| |`awaiting merchant auth`|Payment processing is suspended until the customer authentication initiated in a payment system on the merchant's request is completed.|*Intermediate status*| |`awaiting redirect result`|Payment processing is suspended until the payment system submits a callback with the result to the payment platform. Depending on the result that the payment system submitted the status is set to `success` or `decline`. When processing of the payment only one of the following statuses can be used: either `awaiting redirect result` or `awaiting customer action`. |*Intermediate status*| |`awaiting customer action`|Payment processing is suspended until a customer interacts with a payment system that submits the results of this interaction. Depending on the result that the payment system submitted the status is set to `success` or `decline`. When processing of the payment only one of the following statuses can be used: either `awaiting redirect result` or `awaiting customer action`. |*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status|*Intermediate status*| |`awaiting customer`|Payment processing is suspended until one of additional attempts to perform this payment is completed \(in this case, the status is set to `success` or all additional attempts are used up \(in this case, the status is set to `decline`\). For more information about the Try again payments, see [Payment retries](en_PP_Try_Again.md). |*Intermediate status*| |`decline`|Payment could not be completed.|*Final status*| |`success`|Payment has been completed.|*Final status. Additionally the payment refund is supported.*| |`partially reversed`|Payment amount is partially refunded within the operation day on which the payment was completed.|*Final status*| |`reversed`|Total payment amount is refunded within the operation day on which the payment was completed.|*Final status. Additionally, the refund can be cancelled.*| |`partially refunded`|Partial amount of the payment is returned to the customer.|*Final status. Additionally, the refund can be cancelled.*| |`refunded`|Payment amount is fully refunded after the operation day on which the payment was completed. This status is used if the total amount of payment is returned in one refund or if the total amount of the partial refunds is equal to the total amount of payment.|*Final status. Additionally, the refund can be cancelled.*| ## Statuses of the sale operation {#section_h3k_crr_whb .section} The following table describes the statuses of the `sale` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`awaiting 3ds result`|Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received within the required timeout time, then the payment status is set to `decline`. Normally, the timeout is 30 minutes, but it may differ depending on a provider. For more information about specific timeouts, contact technical support at [support@ecommpay.com](mailto:support@ecommpay.com).|*Intermediate status*| |`awaiting merchant auth`|Payment processing is suspended until the customer authentication initiated in a payment system on the merchant's request is completed.|*Intermediate status*| |`awaiting redirect result`|Operation processing is suspended until the payment system submits a callback with the result to the payment platform. Depending on the result that the payment system submitted the status is set to `success` or `decline`.|*Intermediate status*| |`awaiting customer action`|Operation processing is suspended until a customer interacts with a payment system that submits the results of this interaction. Depending on the result that the payment system submitted the status is set to `success` or `decline`.|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has been completed.|*Final status*| ## Statuses of the payment confirmation operation {#section_egh_3zh_sqb .section} The following table describes the statuses of the `payment confirmation` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has been completed.|*Final status*| ## Statuses of the reversal and refund operations {#section_zfx_crr_whb .section} The following table describes the statuses of the `reversal` or the `refund` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has been completed.|*Final status*| **Parent topic:**[Payment processing](en_platform_payment_model.md) --- # One-time two-step purchase {#en_platform_dms_model} An article about processing one-time purchases with placing an authorisation hold and subsequent debiting of funds \(two steps\), includes the description of the processing workflow, possible statuses and operations. ## Overview {#section_zvh_1rr_whb .section} *One-time two-step purchase* is a payment type which uses two steps to make a one-time transfer of funds from customer to merchant. On the first step, merchant initiates an authorization hold—in other words, the purchase amount is deducted from the credit limit of customer's card account. On the second step, the purchase amount is *captured*, or, in other words, it is debited to the customer account based on the merchant request or after specific time lag. This payment type allows merchant to “hold” the purchase amount and, thus, to ensure that specific amount will be charged, or *captured*, to customer account or, alternatively, to “release” the funds if the situation changes, for instance when the customer cancels hotel booking. ## Payment model {#section_ajd_brr_whb .section} You initiate *the first step* of a purchaseby sending an `auth` request to the payment platform or by opening the payment form in the `purchase` mode with the `auth` operation type specified. Once the payment platform receives the request, it creates an `auth` operation which eventually results in holding funds on customer account. *The first step* may require merchant to issue additional requests: - If the payment requires *customer to be authenticated by using the 3‑D Secure technology*, the payment platform sends to the web service a callback that contains the data required to generate a request to the issuer and suspends the purchase processing until the authentication result information is received.For submitting the information, in case of working via Gate, it is required to send a request with the authentication result—`3ds_result`—, while in case of working via Payment Page, all actions are carried out without the merchant's web service involved. - If the payment requires *customer to be authenticated by the payment system on merchant's request*, the payment platform receives a notification from the payment system and sends to the web service a callback with notification that authentication is required, and then suspends the payment processing in the platform. To continue processing the payment, in case of working via Gate, two `merchant_auth` requests should be sent: `start`—after the customer confirms the payment and `finish`—after the customer enters the validation code, while in case of working via Payment Page, all actions are carried out without the merchant's web service involved. - If any payment stakeholder requests *additional information* \(For example, the payment system may request cardholder address which was missing from the initial request.\), the payment platform sends to the web service a callback that lists the requested parameters and suspends the purchase processing until the required information is received.In case of working via Gate, a request should be sent with the needed information included—`clarification`, while in case of working via Payment Page, all actions are carried out without the merchant's web service involved. *The second step* may be initiated by a request from merchant's web service, through an action in the Dashboard or the payment platform may automatically perform the step after specific time elapses. The merchant initiates *the second step* by sending one of the following requests to the payment platform: - `capture`—this request processing results in a `capture` operation and the customer account is debited for the held amount. - `cancel`—this request processing results in a `cancel` operation and release of the funds held on the customer account. In your `capture` request, you can specify a to-be-debited amount which is different from the initially authorised amount. For more information on how to initiate the second step, refer to your account manager. If the payment method supports refunds, after completing the second step of a one-time two-step purchase, you can refund the purchase. This can be done by sending a `refund` request to the payment platform or as a result of the corresponding action on the payment information tab in the Dashboard interface. For a refundwithin a card payment, depending on the refund time and amount and the payment instrument used for the payment, one of the following operations is initiated: - `reversal` if the refund is initiated within the [operation day](en_glossary.md#) regardless of the purchase amount for a Mastercard card and provided that the total purchase amount is refunded for a card of any other card network; - `refund` if the refund is initiated for a card of any card network after [operation day](en_glossary.md#) and regardless of the amount and within the operation day provided that a partial purchase amount is refunded for a card of all card networks except Mastercard. ![](images/payment%20model/en_gate_payment_model_3.svg) The rest of this section describes any possible statuses of a one-time two-step purchase and the related operations. More information about processing one-time two-step purchasesusing payment cards is provided in the [Payment Page](en_PP_about.md)and [Gate](en_Gate_Integration_About.md) sections, while the information about processing purchases with the use of other payment instruments is provided in the [Payment methods](en_pm_about.md) section. ## Payment statuses {#section_n4r_brr_whb .section} The following table describes the statuses of a one-time two-step purchase. |`error`|Error occurred when request processing. Payment is not performed.|*Final status. The request can be resent with the same payment identifier and the same payment can be retried.*| |`processing`|Payment is being processed.|*Intermediate status*| |`awaiting 3ds result`|Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received within the required timeout time, then the payment status is set to `decline`. Normally, the timeout is 30 minutes, but it may differ depending on a provider. For more information about specific timeouts, contact technical support at [support@ecommpay.com](mailto:support@ecommpay.com).|*Intermediate status*| |`awaiting merchant auth`|Payment processing is suspended until the customer authentication initiated in a payment system on the merchant's request is completed.|*Intermediate status*| |`awaiting redirect result`|Payment processing is suspended until the payment system submits a callback with the result to the payment platform. Depending on the result that the payment system submitted the status is set to `success` or `decline`.|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status|*Intermediate status*| |`awaiting customer`|Payment processing is suspended until one of additional attempts to perform this payment is completed \(in this case, the status is set to `success`or all additional attempts are used up \(in this case, the status is set to `decline`\). For more information about the Try again payments, see [Payment retries](en_PP_Try_Again.md). |*Intermediate status*| |`awaiting capture`|Payment processing is suspended until the web service submits a `capture` request or a `cancel` request.|*Intermediate status*| |`canceled`|A hold placed on funds was cancelled.|*Final status*| |`decline`|Payment could not be completed.|*Final status*| |`success`|Payment has been completed.|*Final status. Additionally, the payment refund is supported.*| |`partially reversed`|Payment amount is partially refunded within the operation day on which the payment was completed.|*Final status*| |`reversed`|Total payment amount is refunded within the operation day on which the payment was completed.|*Final status. Additionally, the refund can be cancelled.*| |`partially refunded`|Partial amount of the payment is returned to the customer.|*Final status. Additionally a partial refund can be cancelled.*| |`refunded`|Payment amount is fully refunded after the operation day on which the payment was completed. This status is used if the total amount of payment is returned in one refund or if the total amount of the partial refunds is equal to the total amount of payment.|*Final status. Additionally, a refund can be cancelled.*| ## The auth operation statuses {#section_h3k_crr_whb .section} The following table describes the statuses of the `auth` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`awaiting 3ds result`|Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received within the required timeout time, then the payment status is set to `decline`. Normally, the timeout is 30 minutes, but it may differ depending on a provider. For more information about specific timeouts, contact technical support at [support@ecommpay.com](mailto:support@ecommpay.com).|*Intermediate status*| |`awaiting merchant auth`|Payment processing is suspended until the customer authentication initiated in a payment system on the merchant's request is completed.|*Intermediate status*| |`awaiting redirect result`|Operation processing is suspended until the payment system submits a callback with the result to the payment platform. Depending on the result that the payment system submitted the status is set to `success` or `decline`.|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has been completed.|*Final status*| ## Statuses of the incremental operation {#section_tnc_3nh_snb .section} The following table describes the statuses of the `incremental` operation. |`decline`|Operation is declined.|*Final status*| |`success`|Operation is completed.|*Final status*| ## Statuses of the capture and cancel operations {#section_wxn_gsr_whb .section} The following table describes the statuses of any `capture` or `cancel` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has been completed.|*Final status*| ## Statuses of the reversal and refund operations {#section_zfx_crr_whb .section} The `reversal` and `refund` operation statuses coincide with the statuses of the `capture` and `cancel` operations. **Parent topic:**[Payment processing](en_platform_payment_model.md) --- # On-demand COF purchase {#en_platform_recurring_model} An article about processing recurring purchases with debiting of funds initiated by the merchant \(unscheduled\), includes the description of the processing workflow, possible statuses and operations. ## Overview {#section_zvh_1rr_whb .section} *On-demand Credential-on-file \(COF\) purchase* is a payment type which uses a single initial request to make one transfer of funds from customer to merchant by using previously stored payment credentials but without validation of the payment instrument \(such as card validation code, or CVC\). The on-demand COF purchases are used for purchases that use the same payment instrument for repeatable purchases with variable amount and no specific schedule, for instance to pay for taxi services. On-demand COF purchases are convenient because they do not require the customer to enter payment credentials and to validate the payment instrument for each purchase. The payment platform supports the following COF payment categories: - *One-click purchases*. Series of debits within such purchases are initiated by the customer and are not based on a schedule or a payment amount. For example, the customer can pay the rent of one or several movies in a virtual cinema using previously saved card credentials. - *Autopurchases*. Series of debits within such purchases are initiated by the merchant and are unscheduled or performed for different amounts. For example, when the customer's account balance falls below specific threshold, funds are withdrawn from the customer's bank account for a top up. Gate can be used to register and process any COF purchases, while Payment Page allows registering any COF purchases and process one-click purchaseswith the use of some payment methods. ## Payment model {#section_ajd_brr_whb .section} A COF purchase becomes available only after its *registration*, which means making an initial payment—a one-time purchase or a payment instrument verification—with the customer's payment data saved in the platform and COF purchase type specified.The set of parameters required for further processing of the COF purchase can differ depending on the payment method in use. When using Gate, you initiate COF purchase by sending a `recurring` requestor a `sale` request to the payment platform. Once the payment platform receives the request, it creates a `recurring`or a `sale` operationrespectively. The created operation eventually results in debiting customer card or account without payment instrument validation. When using Payment Page, to initiate a COF purchase, you specify the `purchase` operation mode and additional parameters required for performing COF purchasesusing a particular payment method in the parameters for opening the payment form. Once the payment form opens, the customer should select the payment instrument for which the COF purchases are registered and confirm payment processing. Authentication is not required. As soon as the customer confirms payment processing, request is sent to the payment platform. Once the payment platform receives the request, it creates the `sale` operation which results in debiting of customer's funds without the verification of the payment instrument. In rare instances, a COF purchase may require you to send another request to submit *additional information* requested by one of the stakeholders, for example to provide cardholder address which is missing from the initial request. In such cases, when working via Gate, a callback with the names of parameters for clarifying information is sent from the platform to the web service and payment processing is suspended until a request with the required information is sent from the web service—`clarification`, while when working via Payment Page, all actions are carried out without the merchant's web service involved. If the payment method supports refunds, after completing an on-demand COF purchase you can *return* your customers their money, if needed. You initiate a refund by sending a `refund` request to the payment platform or select the corresponding action on the payment information tab in the Dashboard interface. For a refundwithin a card payment, depending on the refund time and amount and the payment instrument used for the payment, one of the following operations is initiated: - `reversal` if the refund is initiated within the [operation day](en_glossary.md#) regardless of the purchase amount for a Mastercard card and provided that the total purchase amount is refunded for a card of any other card network; - `refund` if the refund is initiated for a card of any card network after [operation day](en_glossary.md#) and regardless of the amount and within the operation day provided that a partial purchase amount is refunded for a card of all card networks except Mastercard. ![](images/payment%20model/en_gate_payment_model_4.svg "State diagram for on-demand COF purchase") The rest of this section describes any possible statuses of an on-demand COF purchase and the related operations. More information about processing COF purchases is provided in the [Payment Page](en_PP_about.md) and [Gate](en_Gate_Integration_About.md) sections, while the information about processing purchases with the use of other payment instruments is provided in the [Payment methods](en_pm_about.md) section. ## Payment statuses {#section_n4r_brr_whb .section} The following table describes the statuses of any on-demand COF purchase. |`error`|Payment processing is not initiated, error occurred when processing the request received by the payment platform.|*Final status. The request can be resent with the same payment identifier and the same payment can be retried.*| |`processing`|Payment is being processed.|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status.|*Intermediate status*| |`decline`|Payment could not be completed.|*Final status*| |`success`|Payment has completed successfully.|*Final status. Additionally the payment refund is supported.*| |`reversed`|Total payment amount is refunded within the operation day on which the payment was completed.|*Final status. Additionally, the refund can be cancelled.*| |`partially refunded`|The partial amount of payment has returned to a customer.|*Final status. Additionally a partial refund can be cancelled.*| |`refunded`|The the total amount of payment was returned to a customer after the business day the initial purchase had been completed. This status is used if the total amount of payment is returned in one refund or if the total amount of the partial refunds is equal to the total amount of payment. |*Final status. Additionally a refund can be cancelled.*| ## The recurring operation statuses {#section_h3k_crr_whb .section} The following table describes the statuses of the `sale` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`awaiting clarification`|Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to `decline`.|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has completed successfully.|*Final status*| ## Statuses of the reversal and refund operations {#section_zfx_crr_whb .section} The `reversal` and `refund` operation statuses coincide with the statuses of the `recurring` operation. **Parent topic:**[Payment processing](en_platform_payment_model.md) --- # COF purchase with automatic debiting {#en_platform_sheduled_recurring_model} An article about processing recurring purchases with automatic debiting of funds \(according to a set schedule\), includes the description of the processing workflow, possible statuses and operations. ## Overview {#section_zvh_1rr_whb .section} *Credential-on-file \(COF\) purchase with automatic debiting* is a payment type which uses an initial request to initiate a series of fund transfers from customer to merchant by using previously stored payment credentials without validation of the payment instrument \(such as card validation code, or CVC\). This payment type includes *regular purchases*. COF purchases with automatic debiting are used for purchases in which the same payment instrument for repeatable miscellaneous purchases with fixed amount and schedule, for instance to pay monthly fee for a subscription. COF purchases with automatic debiting are convenient for the customer and the merchant because they can be sure that payments will be performed automatically, with no additional actions on their part. ## Payment model {#section_ajd_brr_whb .section} A COF purchase becomes available only after its *registration*, which means making an initial payment—a one-time purchase or a payment instrument verification—with the customer's payment data saved in the platform and COF purchase type specified.The set of parameters required for further processing of the COF purchase can differ depending on the payment method in use. If all required parameters were specified during COF purchase registration, the merchant or the customer does not need to initiate the scheduled COF purchase, as in this case withdrawal of funds is initiated automatically by the payment platform. A separate `recurring` operation is used for each withdrawal. If required, you can change the payment schedule and/or amount or even cancel the payment altogether. To change the payment schedule and/or amount, you need to submit an `update` request to the payment platform via Gate. To cancel the payment, you submit a `cancel` request. To initiate the `update` and `cancel` requests, you use the `recurring_update` and `recurring_cancel` operations, respectively. In rare instances, a COF purchase with automatic debiting may require you to send another request to submit *additional information* requested by one of the stakeholders, for example to provide cardholder address which is missing from the initial request. In such cases, when working via Gate, a callback with the names of parameters for clarifying information is sent from the platform to the web service and payment processing is suspended until a request with the required information is sent from the web service—`clarification`. If the payment method supports refunds, after completing a COF purchase with automatic debiting you can *return* your customers their money, if needed. The total amount of refund cannot be larger than the total debited amount. You initiate a refund by sending a `refund` request to the payment platform or select the corresponding action in the payment information tab of the Dashboard interface. Refund is performed by using the `refund` operation. ![](images/payment%20model/en_gate_payment_model_5.svg) The rest of this section describes any possible statuses of a COF purchase with automatic debiting and the related operations. More information about processing COF purchases is provided in the [Gate](en_Gate_Integration_About.md) section. ## Payment statuses {#section_n4r_brr_whb .section} The following table describes the statuses of any COF purchase with automatic debiting. |`error`|Payment processing is not initiated, error occurred when processing the request received by the payment platform.|*Final status. The request can be resent with the same payment identifier and the same payment can be retried.*| |`processing`|Payment is being processed.|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status|*Intermediate status*| |`scheduled recurring processing`|Payment is in progress. Automatic debiting is pending according to the prearranged schedule.|*Intermediate status*| |`decline`|Payment could not be completed.|*Final status*| |`success`|Payment has completed successfully.|*Final status. Additionally the payment refund is supported.*| |`partially refunded`|The partial amount of payment has returned to a customer and all series of debits within the payment are completed.|*Final status. Additionally a partial refund can be cancelled.*| |`refunded`|The the total amount of payment was returned to a customer and all series of debits within the payment are completed. |*Final status. Additionally a refund can be cancelled.*| ## The recurring operation statuses {#section_h3k_crr_whb .section} The following table describes the statuses of the `sale` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`awaiting clarification`|Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to `decline`.|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has completed successfully.|*Final status*| ## The recurring\_update and recurring\_cancel operations statuses {#section_h3k_ytr_whb .section} The following table describes the statuses of the `recurring_update` and `recurring_cancel` operations. |`processing`|Operation is being processed.|*Intermediate status*| |`decline`|Operation is declined.|*Final status*| |`success`|Operation is completed.|*Final status*| ## The refund operation statuses {#section_glx_sqm_g3b .section} The `refund` operation statuses coincide with the `recurring` operation statuses. **Parent topic:**[Payment processing](en_platform_payment_model.md) --- # Payment link purchase {#en_platform_invoice_model} An article about processing purchases with the use of payment links, includes the description of the processing workflow, possible statuses and operations. ## General information {#section_ltv_433_tkb .section} *Payment link purchase* is a payment type which uses an initial request to generate a web link that customers can click to make purchases that involve a one-timeor recurring transfer of funds from the customer to the merchant.As a rule, payment link purchases are used for one-time payments with or without the authorisation hold. At the same time, if needed, payment link purchases can be used for registering [COF purchases](en_Gate__payments_on_saved_data.md), while with certain payment methods payment links can be used for obtaining the customer's consent to registration of a COF purchase, without actual withdrawal of funds. This payment type is useful when you need to accept online payments that are not attached to a certain time, physical POS, or online site. You can either have the Ecommpay payment platform send payment link to the customer via email, or you can share it via any other delivery media, for example, messengers or social media. ## Payment model {#section_dy1_z33_tkb .section} To create a payment link, you can send an `invoice/create` request to the Gate API or select the corresponding action in the Dashboard interface. When the payment platform receives the request, it creates an `invoice` operation that results in: - generating the payment link, - delivering it to your web service, - sending it to the customer if it was specified in the request. Depending on which interface was used to initiate the payment link creation, you can receive the created payment link in a callback sent to the web service or via Dashboard. The link is sent to the customer automatically via the payment platform if it was specifically indicated and the customer's email was provided. For this purpose, you can use parameters `send_email` and `email` in the request to the Gate API or the **Send e-mail to the Customer** toggle switch and the **Customer e-mail** field in Dashboard. Note that if the link is not intended to be sent via the payment platform and will be sent via the web service instead, the `invoice` operation is technically finalised after the payment link has been delivered to your web service. Once the link has been created and delivered to the web service, but before the customer confirms the purchase, you can deactivate the payment link if necessary. To do so, you need to send an `invoice/cancel` request to the payment platform or use the **Deactivate** toggle switch in the list of payment links in Dashboard. By clicking the payment link, your customers open Payment Page where they can enter their payment information and complete the purchase. Then,the payment is processed according to one of the following scenarios depending on the `operation_type` parameter value: - *Processing a purchase \([details](en_platform_sms_model.md)\), with or without registration of a COF purchase*   In this processing scenario, the payment platform creates a `sale` operation that eventually debits the customer's account. - *Placing an authorisation hold \([details](en_platform_dms_model.md)\), with or without registration of a COF purchase*   In this processing scenario, the payment platform creates an `auth` operation that results in authorisation hold of funds on customer account. Capturing the funds or cancelling the hold can be initiated in one of the following ways: - By request from the merchant's web service. - By the merchant employees that use Dashboard for this purpose. - By the payment platform after a timeout. - *Registering a COF purchase*   In this processing scenario, the COF purchase is registered without the customer's funds deducted or held. The payment platform creates a `contract_registration` operation that results in a registered COF purchase. For each of these scenarios that involve payment links, the payment platform may perform some [auxiliary procedures](en_gate_procedures.md), though no additional input from the web service is required because all operations are performed by Payment Page. *Refunds* can be issued for all successful payments completed by using payment linksif refunds are supported for the specific payment methodand the payment processing scenario. To initiate a refund, you need to submit a `refund` request or select the corresponding action in the payment information tab in the Dashboard interface. For a refundwithin a card payment, depending on the refund time and amount and the payment instrument used for the payment, one of the following operations is initiated: - `reversal` if the refund is initiated within the [operation day](en_glossary.md#) regardless of the purchase amount for a Mastercard card and provided that the total purchase amount is refunded for a card of any other card network; - `refund` if the refund is initiated for a card of any card network after [operation day](en_glossary.md#) and regardless of the amount and within the operation day provided that a partial purchase amount is refunded for a card of all card networks except Mastercard. ![](images/payment%20model/en_gate_payment_model_invoice.svg "State diagram for a two-step payment link purchase") The rest of this section describes any possible statuses of a payment link purchase and the related operations. More information about processing payment link purchases is provided in the [Gate](en_Gate_Integration_About.md)and [Dashboard](en_dbl_about.md) sections. ## Payment statuses {#section_n4r_brr_whb .section} The following table describes the statuses of a payment link purchase. |`error`|Payment not initiated because of request verification error|*Final status. The request can be resent with the same payment identifier and reattempt to perform the payment.*| |`awaiting payment`|Payment processing initiated, waiting for payment link submission|*Intermediate status*| |`expired`|Payment declined because of payment link expiry|*Final status*| |`invoice canceled`|Payment declined by merchant|*Final status*| |`invoice sent`|Payment processing initiated, payment link sent|*Intermediate status*| |`processing`|Payment is being processed|*Intermediate status*| |`awaiting 3ds result`|Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received within the required timeout time, then the payment status is set to `decline`. Normally, the timeout is 30 minutes, but it may differ depending on a provider. For more information about specific timeouts, contact technical support at [support@ecommpay.com](mailto:support@ecommpay.com).|*Intermediate status*| |`awaiting redirect result`|Payment processing is suspended until the payment system submits a messagewith the result or that the customer performed required actions. Depending on the result the payment system submitted, the status is set to `awaiting finalization`,`success`, or `decline`.|*Intermediate status*| |`awaiting finalization`|Payment processing is suspended until the payment system submits a message with the result. No additional actions of the customer are required, and depending on the result the payment system submitted, the status is set to `success` or `decline`.|*Intermediate status*| |`awaiting clarification`|Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to `decline`.|*Intermediate status*| |`awaiting customer`|Payment processing is suspended until one of additional customer attempts to perform the payment is successfully completed—the status is set to `success`—or the maximum amount of the additional attempts is exceeded—the status is set to `decline`. \(For more information, see [Payment retries](en_PP_Try_Again.md).\)|*Intermediate status*| |`awaiting capture`|Payment processing is suspended until the web service submits a `capture` or a `cancel` request.|*Intermediate status*| |`canceled`|Authorisation hold previously placed by a `auth` request has been cancelled.|*Final status*| |`decline`|Payment declined|*Final status*| |`success`|Payment completed|*Final status. Also, refund is supported.*| |`partially reversed`|Partial refund performed before closing the business day the initial payment was completed|*Final status*| |`reversed`|Full refund performed before closing the business day the initial payment was completed|*Final status. Also, refund can be reversed.*| |`partially refunded`|Payment partially refunded|*Final status. Also, refund can be reversed.*| |`refunded`|Full refund performed after closing the business day when the initial payment was completed. The refund is performed in a lump sum or in several sums that in total equal to the initial purchase amount.|*Final status. Also, refund can be reversed.*| ## The statuses of the invoice operation {#section_vhh_1j3_tkb .section} The following table describes the statuses of the `invoice` operation. |`awaiting payment`|Operation initiated, the payment link delivered to the web service. If the payment link was requested to be sent to the customer via the Ecommpay payment platform, then waiting to send the email with the link. If the payment link was not requested to be sent via the Ecommpay payment platform and will be sent via the web service, then the operation has been completed. |*Intermediate statusif the link is sent via the platform.* *Final status if the link is sent via the merchant's web service* | |`expired`|Operation completed, the payment link expired|*Final status*| |`invoice canceled`|Operation cancelled by the merchant|*Final status*| |`invoice sent`|Operation completed, the payment link sent|*Final status*| ## The statuses of the saleand auth operations {#section_oxc_cw3_tkb .section} The following table describes the statuses for the `sale`and `auth` operations. |`processing`|Operation is being performed|*Intermediate status*| |`awaiting 3ds result`|Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received within the required timeout time, then the payment status is set to `decline`. Normally, the timeout is 30 minutes, but it may differ depending on a provider. For more information about specific timeouts, contact technical support at [support@ecommpay.com](mailto:support@ecommpay.com).|*Intermediate status*| |`awaiting redirect result`|Operation processing is suspended until the payment system submits a callback with the result to the payment platform. Depending on the result returned by the payment system, the status is set to `success` or `decline`.|*Intermediate status*| |`awaiting clarification`|Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to `decline`.|*Intermediate status*| |`decline`|Operation declined|*Final status*| |`success`|Operation completed|*Final status*| ## The statuses of the capture and cancel operations {#section_gnf_fw3_tkb .section} The following table describes the statuses for the `capture` and `cancel` operations. |`processing`|Operation is being processed|*Intermediate status*| |`awaiting clarification`|Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to `decline`.|*Intermediate status*| |`decline`|Operation declined|*Final status*| |`success`|Operation completed|*Final status*| ## The statuses of the contract registration operation {#section_o3q_bxg_j2c .section} |`processing`|Operation is being processed|*Intermediate status*| |`awaiting clarification`|Operation processing is suspended until the payment platform receives additional information. If the payment platform does not receive the required information within 30 minutes, the status is set to `decline`.|*Intermediate status*| |`awaiting redirect result`|Operation processing is suspended until the payment system submits a message. Depending on the result the payment system submitted, the status is set to `success` or `decline`.|*Intermediate status*| |`decline`|Operation declined|*Final status*| |`success`|Operation completed|*Final status*| ## The statuses of the reversal and refund operations {#section_mvr_hw3_tkb .section} The `reversal` and `refund` operations use the same statuses as the `capture` and `cancel` operations. **Parent topic:**[Payment processing](en_platform_payment_model.md) --- # Payout {#en_platform_payout_model} An article about processing payouts, includes the description of the processing workflow, possible statuses and operations. ## Overview {#section_htd_ylv_cjb .section} *Payout* is a payment type which uses one request to make a one-time transfer of funds from merchant to customer. Basically, the payment platform performs payouts on demand \(one-time payments\); though, you can implement bulk payouts by using Dashboard. In the latter case, you can have the required payouts generated automatically. For more information about bulk payouts, see [Monitoring and performing payments](en_dbl_payments.md#). ## Payment model {#section_ajd_brr_whb .section} You initiate a payout by sending a `payout` request to the payment platform, opening the payment form in the Payout mode, or selecting the corresponding action in the **Payouts** section of the Dashboard interface. Once the payment platform receives the payout request, it creates a `payout` operation which eventually results in crediting the funds to the customer card or account. In some cases, a payout may require you to send another request to submit *additional information* requested by one of the stakeholders, for example to provide cardholder address which is missing from the initial request. In this case, the payment platform sends to the web service a callback with the names of the missing parameters, suspends the payout processing, and waits until the web service submits a `clarification` request with the values for the missing parameters.The procedure is currently not supported for alternative payment methods. If a payment system or a provider assigns the payout the `success` status but for some reason the customer's account cannot be credited, a reversal of the payout is initiated in the payment platform after receiving a callback with information about crediting failure. The reversal is performed manually by the Ecommpay technical support specialists or, for some payment methods, automatically. The reversal is performed by initiating the `payout reversal` operation. ![](images/payment%20model/en_gate_payment_model_14.svg "State diagram for payout via Payment Page") ![](images/payment%20model/en_gate_payment_model_12.svg "State diagram for payout via Gate") The rest of this section describes any possible statuses of a payout and operations related with the payout. More information about processing payoutsusing payment card is provided in the [Payment Page](en_PP_about.md),[Gate](en_Gate_Integration_About.md), and [Dashboard](en_dbl_about.md) sections, while the information about processing payouts with the use of alternative payment instruments is provided in the [Payment methods](en_pm_about.md) section. ## Payment statuses {#section_n4r_brr_whb .section} The following table describes payout statuses. |`error`|Error occurred when request processing. Payment is not performed.|*Final status. The request can be resent with the same payment identifier and reattempt to perform the payment.*| |`awaiting payout completion`|Payment processing has been initiated, awaiting the payout confirmation by the customer.|*Intermediate status*| |`processing`|Payment is being processed.|*Intermediate status*| |`awaiting clarification`|Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to `decline`.|*Intermediate status*| |`decline`|Payment could not be completed.|*Final status*| |`success`|Payment has been completed successfully.|*Final status. Additionally the payment refund is supported.*| |`reversed`|Payment has been reversed.|*Final status.*| ## The payout operation statuses {#section_h3k_crr_whb .section} The following table describes the statuses of any `payout` operation. |`awaiting payout completion`|Operation processing has been initiated, awaiting the payout confirmation by the customer.|*Intermediate status*| |`processing`|Operation is being processed.|*Intermediate status*| |`awaiting clarification`|Operation processing is suspended until the payment platform receives the additional information from the customer. If the payment platform does not receive the required information within 30 minutes, the status is set to `decline`.|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has been completed successfully.|*Final status*| ## The payout reversal operation statuses {#section_n3y_j4g_ppb .section} The following table describes the statuses of any `payout reversal` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`decline`|Operation is declined.|*Final status*| |`success`|Operation is completed.|*Final status*| **Parent topic:**[Payment processing](en_platform_payment_model.md) --- # Payment instrument verification {#en_platform_account_verification_model} An article about verifying a payment instrument \(by debiting a zero amount\), includes the description of the processing workflow, possible statuses and operations. ## Overview {#section_zvh_1rr_whb .section} *Payment instrument verification* is a payment type in which the customer card or account is validated by either transferring a dummy \(zero\) amount from customer to merchantor by authorizing a specific amount \(non-zero\) on the customer's card or account and then voiding the transfer or the authorization. The authorization amount can be changed on merchant's request. Normally, the authorized amount is released shortly after the operation, but in some instances the authorized amount can be held up to 45 days. This payment type can be used, for example, for registering COF purchases. **Note:** For information about the availability of payment instrument verification, contact the Ecommpay account manager. ## Payment model {#section_ajd_brr_whb .section} You initiate the verificationby sending the `account verification` request to the payment platform or by opening the payment form in the `card_verify` mode. Once the payment platform receives the request, it creates an `account verification` operation. Payment instrument verification may require the merchant to send additional requests: - If the payment requires *customer to be authenticated by using the 3‑D Secure service*, the payment platform sends to the web service a callback with the data required to generate a request to the issuer and suspends payment processing until the information about the authentication result is received.For this, in case of working via Gate, it is required to send a request with the authentication result—`3ds_result`, while in case of working via Payment Page, all actions are carried out without the merchant's web service involved. - If any payment stakeholder requests *additional information* \(for example, the payment system may request cardholder address which was missing from the initial request.\), the payment platform sends to the web service a callback that lists the requested parameters and suspends the purchase processing until the required information is received.In case of working via Gate, a request should be sent with the needed information included—`clarification`, while in case of working via Payment Page, all actions are carried out without the merchant's web service involved. ![](images/payment%20model/en_gate_payment_model_7.svg) The rest of this section describes any possible statuses of a payment instrument verification and related operations. More information about processing payment instrument verification is provided in the [Payment Page](en_PP_about.md)and [Gate](en_Gate_Integration_About.md) sections. ## Payment statuses {#section_n4r_brr_whb .section} The following table describes the statuses of payment instrument verification. |`error`|Error occurred when request processing. Payment is not performed.|*Final status. The request can be resent with the same payment identifier and the same payment can be retried.*| |`processing`|Payment is being processed.|*Intermediate status*| |`awaiting 3ds result`|Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received within the required timeout time, then the payment status is set to `decline`. Normally, the timeout is 30 minutes, but it may differ depending on a provider. For more information about specific timeouts, contact technical support at [support@ecommpay.com](mailto:support@ecommpay.com).|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status.|*Intermediate status*| |`decline`|Payment could not be completed.|*Final status*| |`success`|Payment has been completed.|*Final status. Additionally the payment refund is supported.*| ## The account verification operation statuses {#section_h3k_crr_whb .section} The following table describes the statuses of any `account verification` operation. |`processing`|Operation is being processed.|*Intermediate status*| |`awaiting 3ds result`|Payment processing is suspended until the information about the 3‑D Secure authentication result is received. If this information is not received within the required timeout time, then the payment status is set to `decline`. Normally, the timeout is 30 minutes, but it may differ depending on a provider. For more information about specific timeouts, contact technical support at [support@ecommpay.com](mailto:support@ecommpay.com).|*Intermediate status*| |`awaiting clarification`|Payment processing is suspended until the required additional information is received. If the information is not received within 30 minutes, the payment is assigned the `decline` status.|*Intermediate status*| |`decline`|Operation could not be completed.|*Final status*| |`success`|Operation has been completed.|*Final status*| **Parent topic:**[Payment processing](en_platform_payment_model.md) --- # Handling payment processing information {#en_platform_payment_information} Articles about receiving and processing data about payments executed via the platform in order to analyse, monitor, and respond to payment processing activity. To implement efficient processes of monitoring, analysing, and responding when working with the payment platform, you need to configure receiving and processing payment information. This section contains essential information that can help you with setting up: - [Overview](en_platform_payment_information_overview.md)—a brief review of main ways to receive and process information about payments and operations, with the description of key differences and specific characteristics. - [Handling callbacks](en_platform_callbacks.md#)—an article about working with callbacks which are programmatic messages that allow you to receive up-to-date information significant for processing of each payment. - [Handling operation processing information](en_platform_payment_info_codes.md)—an article about statuses and codes that are used in the platform to communicate the statuses of operations in progress and the reasons for declines. In addition, to learn more about working with payment information, you can refer to: - An article about sending requests to the the Gate API in order to receive current information about individual payments—[Checking current payment information](en_Gate_payment_status_request.md#). - Articles about using interfaces that provide you with different options to monitor payment processing—[Dashboard](en_dbl_about.md)and [Using Data API](en_dbl_api_protocol.md). - **[Overview](en_platform_payment_information_overview.md)** An article with a brief review comparing main ways of receiving and processing information about payments and operations. - **[Handling callbacks](en_platform_callbacks.md#)** An article about working with callbacks which are programmatic messages that allow merchants to receive up-to-date information significant for processing of each payment, includes the description of callback types and data structures used in them. - **[Handling operation processing information](en_platform_payment_info_codes.md)** An article about statuses and codes that are used in the platform to communicate the statuses of operations and the reasons for declines. **Parent topic:**[Platform](en_platform_about.md) --- # Overview {#en_platform_payment_information_overview} An article with a brief review comparing main ways of receiving and processing information about payments and operations. When payments are processed, it is important for merchants to remain timely informed. They need to monitor statuses of individual payments and operations, consolidated payment processing results filtered by different attributes, finalised financial data, and so on. The platform offers a wide range of specific capabilities to ensure that merchants stay up-to-date on all necessary data required for accomplishing these tasks. The main capabilities are: - *Receiving callbacks*. If you need your web service to be automatically updated with the current information about individual payments, use callbacks \([learn more](en_platform_callbacks.md#)\). They are sent from the platform to the web service in predetermined cases and contain a flexibly configured set of parameters and a signature.Callbacks can be sent without any delay when their trigger event is registered in the platform or with a specified delay. When payments are processed via Gate, you are required to set up handling of the *prescriptive* callbacks that are triggered by the necessity of a certain action. In other cases, you can opt out of receiving callbacks, but it is highly recommended that you use them because callbacks are the fastest and the most reliable option for obtaining information about each payment. - *Using the Gate API.* If you need to receive up-to-date information about individual payments within the time period determined by the web service specifics and not the platform\(for example, when certain events occur in the web service, or at a specified time after the payment was initiated\), you can use specialised requests to the Gate API \([learn more](en_Gate_payment_status_request.md#)\). Payment status requests are synchronous: the responses to them are sent within one HTTP session and contain a configurable set of parameters and a signature.As in case with callbacks, responses to payment status requests provide immediate information, updated without delays. - *Using the Data API*. If you need automated retrieval of data on payment processing results for specific time periods, you can use the Data API \([learn more](en_dbl_api_protocol.md)\).This can be relevant, for example, when you utilise the in-house or external BI system either instead of Dashboard or as a supplementary tool. The Data API allows you to retrieve operation data\(including fraudulent operation data\), chargeback data, and balance information.Since the Data API retrieves information from a remote long-term storage, it can take up to several minutes for updates to be reflected. - *Using the Dashboard interface*. If you need to receive up-to-date information about payment processing results via a user interface, you can use Dashboard \([learn more](en_dbl_about.md)\). This interface ensures a comprehensive approach to working with payment processing data: it allows you to monitor information about payments and operations from different angles and use various registries, information tabs, and reports.In addition, Dashboard allows you not only to view different information, but also to perform a number of actions to manage payments, whitelists and blacklists of payment criteria, chargebacks, balances, and so on. At the same time, keep in mind that as in the case with the Data API, Dashboard retrieves information from a remote long-term storage, so it can take up to several minutes for updates to be reflected. Along with that, when you work with specific tools\(for example, with SDKs for mobile applications\), there can be other ways to receive payment processing information. They are described in the articles about these tools and can be used in addition to the main capabilities described above. Overall, it should be noted that the most up-to-date information is available via callbacks and requests to the Gate API, the most exhaustive—via Dashboard and the Data API, while the most convenient way to deal with payment processing information is to combine available capabilities with consideration to the web service specifics. To learn more about this topic, explore this documentation or contact the technical support. **Parent topic:**[Handling payment processing information](en_platform_payment_information.md) --- # Handling operation processing information {#en_platform_payment_info_codes} An article about statuses and codes that are used in the platform to communicate the statuses of operations and the reasons for declines. The current state of the operation created as part of the payment in the Ecommpay payment platform is indicated by its status. The operation status may be received from the payment platform in the intermediate and final callbacks and in responses to the request for [Checking current payment information](en_Gate_payment_status_request.md#) in the operation.status parameter, as well as may be seen in Dashboard. In addition to statuses, the payment platform uses service codes and messages, which specify information about the operation performing or the possible reasons of operation declining, including those received from external payment systems. All the response and error codes, as well as its related messages are unified in the payment platform so that it is convenient to provide the information. The unified codes and messages are sent to the merchant web service same way as the status in the operation.code and operation.message parameters. You can also view this information in Dashboard in the payment details. ``` "operation": { "id": 65658000001111, "type": "sale", "status": "success", // operation status "date": "2024-08-30T13:58:12+0000", "created_date": "2024-08-30T13:58:06+0000", "request_id": "0a5cb476be3a55010fb050ec1c1cbd35361ac912a3", "sum_initial": { "amount": 10000, "currency": "EUR" }, "sum_converted": { "amount": 10000, "currency": "EUR" }, "code": "0", // code specifying the status "message": "Success" // explanation to the code } ``` If an error occurs while operation request processing, it is indicated by the `error` request status. Since the operation is not created in this case, the payment platform sends error data in a synchronous response in the code and message parameters. For more information and examples of synchronous error responses, see [Response format](en_gate_interaction_organisation.md#). When working with errors, some actions may be required on the merchant's side. Various recommendations are provided according to the received status and error code are provided in the table below. |Statuses|Comment|Action| |--------|-------|------| |`success`|Operation is performed. There are no further actions required|No action required| |- `awaiting 3ds result` - `awaiting redirect result` - `awaiting clarification` - `awaiting customer action` - `awaiting merchant auth` - `processing` |Operation performing is in progress|It is necessary to wait| |`decline`|Operation performing was declined: by a customer, by exceeding the requests number limit, by net connection failure or by insufficient funds on the customer account at current moment|Resend the request or Resend the request later| |Operation performing was declined due to incorrect data in the request. Eliminate the error on your side by correcting the request or contact the technical support for help|Correct the request before resending| |Operation processing was declined due to a technical failure, contact the technical support|Contact the technical support| |Operation performing was declined by the risk control system \(RCS\) or due to other reasons that cannot be eliminated. Comments on the decline can be obtained from the technical support|No action required| |`error`|Error occurred while operation request processing. Operation is not performed|Correct the request before resending| The possible values of the codes and the messages that are displayed to customers, and suggested to the merchant further actions are given in the tables below. ## General codes {#section_ick_2ds_xzb .section} |Code|Message|Description|Action| |----|-------|-----------|------| |0|Success|Operation successfully completed|No action required| |100|General decline|Operation was declined. Payment platform general error|Contact the technical support| |104|Declined by 3DS check|Operation was declined due to unsuccessful authentication|Resend the request| |108|Customer has not returned from ACS|Operation was declined. Customer has not returned from ACS page of the issuing bank.|Resend the request| |109|Declined by AVS check|Operation was declined due to the incorrect entry of billing address|Correct the request before resending| |301|Cancelled|Operation was cancelled by the participant|Resend the request| |303|Access denied|Request is prohibited due to lack of permits|Contact the technical support| |309|The amount received during conversion exceeds the limit|Operation was declined as the payment amount exceeds the limit specified by the payment provider|Correct the request before resending| |310|This operation is not allowed by project settings|Operation was declined. This type of operation is not available for the project.|Contact the technical support| |314|Provider is not available now to perform the operation|Operation was declined as the provider is not available now|Resend the request later| |318|Use of token\_data is disabled for the project|Operation was declined because the capability of processing payments with network tokens is not enabled for the project|Contact the technical support| |319|There is not enough data to create an operation|Operation was declined because the request did not contain the data required for creating an operation|Correct the request before resending| |402|RCS reject. Declined by Risk System|Operation was declined due to suspicion of a fraud. General anti-fraud decline|No action required| |501|Internal error|An internal error has occurred|Contact the technical support| |502|Validation error|Received data cannot be validated|Contact the technical support| |504|Insufficient funds on the balance|Request is prohibited due to lack of funds|Contact the technical support| |601|Try again|An error has occurred|Resend the request| |602|Network error|A network error occurred with one of the external services|Resend the request| |603|Auto decline|Operation was declined because of auto decline settings|Resend the request| |604|Payout Session Terminated. UUID Expired|Operation was declined because the `uuid` is no longer valid|Resend the request with the valid `uuid`| |702|Malformed request|Request was rejected due to malformed format|Correct the request before resending| |903|Exceeded allowed amount for refund|Total amount of refunds by the bank card exceeds the amount of init payments|Contact the technical support| |904|Exceeded allowed amount for payout|The bank card exceeded the limits on the amount for payouts|Contact the technical support| |2003|Invalid JSON string|Invalid JSON string was sent in the request|Correct the request before resending| |2004|Required field not provided|Required parameter was not sent in the request|Correct the request before resending| |2014|Addendum data disallowed with COF purchase registration|Addendum data in request with COF purchase registration is not allowed|Correct the request before resending| |2061|Avs Data Not Found|Operation was declined. The AVS data is needed to proceed|Try to correct the request before resending| |2123|Account verification is not allowed|Account verification is not allowed|Correct the request before resending| |2124|Invalid Customer ID|Invalid customer\_id was sent in the request|Correct the request before resending| |2147|Lock Error|Operation was declined due to time-out.|Resend the request later| |2154|Customer ID is required for project|The project settings require to pass the customer\_id parameter in the request|Correct the request before resending| |2261|Country not found|Parameter country was not found in the request|Correct the request before resending| |2426|Invalid Email|Invalid email parameter was sent in the request|Correct the request before resending| |2442|Project ID not found|Parameter project\_id was not found in the request|Correct the request before resending| |2466|Declined By Pares Settings|An incorrect 3‑D Secure authentication code was entered or an error occurred during the entering|Resend the request| |2467|3DS SDK request is not supported|The `device_channel` parameter specified for performing 3‑D Secure contains the App-based value that is not allowed for the payment initiated by this request|Create a new request with the allowed value for the `device_channel` parameter and a new payment identifier or contact the technical support| |2468|3DS 3RI request is not supported|The `device_channel` parameter specified for performing 3‑D Secure contains the 3DS Requestor Initiated value that is not allowed for the payment initiated by this request|Create a new request with the allowed value for the `device_channel` parameter and a new payment identifier or contact the technical support| |2541|Unknown Payment Method|Unknown payment\_method was sent in the request|Correct the request before resending| |2606|Withdrawal without initial payment is not allowed|Withdrawal without initial payment is not allowed|Correct the request before resending| |2609|Invalid day of birth|Invalid day\_of\_birth was sent in the request|Correct the request before resending| |2610|Invalid Country|Invalid country was sent in the request|Correct the request before resending| |2611|Invalid City|Invalid city was sent in the request|Correct the request before resending| |2641|Invalid Bank Code or Currency|Invalid bank\_id or currency was sent in the request|Correct the request before resending| |2642|Operation amount is greater than limit|Operation amount is greater than allowed limit|Correct the request before resending| |2701|Rules Failed Code|Operation processing failed due to business rules|Contact the technical support| |2801|Bank ID not found|Parameter bank\_id was not found in the request|Correct the request before resending| |2945|Invalid operation type for try again request|Invalid operation type for try again the request|Correct the request before resending| |2949|Invalid amount for try again request|Invalid amount for try again the request|Correct the request before resending| |3001|Invalid day of birth from UK merchant|Invalid day of birth was sent in the request from UK merchant|Correct the request before resending| |3002|Invalid Post Code from UK merchant|Invalid post code was sent in the request from UK merchant|Correct the request before resending| |3003|Invalid Surname from UK merchant|Invalid surname was sent in the request from UK merchant|Correct the request before resending| |3004|Invalid Street Address from UK merchant|Invalid street address was sent in the request from UK merchant|Correct the request before resending| |3020|Period of card validity is required for the project|Card expiry date is required but was not sent in the request|Correct the request before resending| |3021|Card expired|Card has expired|Correct the request before resending| |3022|Customer is not presented in saved card request|Customer was not sent in the request for payment by using a saved card|Correct the request before resending| |3023|Provided currency disabled for Project ID|Provided currency is disabled for the project\_id|Contact the technical support| |3024|Invalid Payment ID|Invalid payment\_id was sent in the request|Correct the request before resending| |3026|Internal Decline|Payment performing through this payment system is not available|Contact the technical support| |3027|Invalid token provided|Invalid token was sent in the request|Correct the request before resending| |3028|Insufficient funds on merchant balance|Insufficient funds on the balance to perform payout|Contact the Ecommpay key account manager| |3029|Operation with expired card is not allowed for this provider|Operation performing was declined due to the provider does not allow using an expired card|Contact the technical support| |3041|Payment ID already exists|Payment ID already exists in the system|Correct the request before resending| |3060|Current payment or operation status does not allow this action|Current payment or operation status does not allow the attempted action|Contact the technical support| |3061|Transaction not found|Payment is not found in the system|Resend the request or contact the technical support| |3062|Payment details not received|Failed to get payment details at the moment|Resend the request later| |3081|State Machine Flow Break|Error payment processing|Contact the technical support| |3101|Card not found|Card data from Token does not belong to the customer in the request|Correct the request before resending| |3102|Invalid payment constraint|Operation by the card failed to validate system business rules|Contact the technical support| |3103|Payout was declined due to constraint for card type|Payout was declined due to issuer restrictions related to card type|Contact the technical support| |3104|Payment Constraint Invalid Payout Amount|Maximum payout limit has been exceeded|Correct the request before resending| |3105|Card country is forbidden|Performing an operation with the card issued in the specified country is not allowed|Correct the request before resending| |3106|Payment Constraint Invalid Monthly Payout|Monthly payout limit has been exceeded|Resend the request later| |3107|Payout Constraint, card without successful purchase|Payout is declined because the purchase that contains the information about the payout recipient's card could not be identified|Contact the technical support| |3108|Payment Constraint Invalid Weekly Payout|Weekly payout limit has been exceeded|Resend the request later| |3109|Payment Constraint Invalid 24 Hour Payout|Daily payout limit has been exceeded|Resend the request later| |3110|Payment Constraint Monthly payout operations number exceeded|Monthly limit on the number of payouts has been exceeded|Resend the request later| |3111|Payment Constraint Weekly payout operations number exceeded|Weekly limit on the number of payouts has been exceeded|Resend the request later| |3112|Payment Constraint 24 hour payout operations number exceeded|Daily limit on the number of payouts has been exceeded|Resend the request later| |3117|Operation is prohibited because residual payment amount is less than one minor in USD|The operation is declined because the difference between the actual payment amount and the operation amount is less than required \(0.01 USD\)|Correct the request before resending: specify a lesser amount or a full amount of the payment| |3118|Operation amount will be less than one minor unit after conversion by IPS|The operation is rejected because the operation amount will be less than one minor unit after the conversion performed by the global card network|Correct the request before resending| |3119|Request currency does not match channel currency|Currency specified in the request does not match the channel currency|Correct the request before resending| |3120|The payment amount should not exceed 25 USD for the MCC|Operation performing was declined as the payment amount for the MCC should not exceed `25 USD` or equivalent amount|Correct the request before resending| |3121|Invalid currency|Invalid currency was sent in the request|Correct the request before resending| |3123|Invalid API Key|Invalid API Key was sent in the request|Correct the request before resending| |3124|Invalid certificate|Error while request processing|Contact the technical support| |3125|Incremental authorization requests are forbidden for the MCC|Requests to increment authorization amount are forbidden for the MCC|Correct the request before resending| |3141|CVV is required|CVV is required in the request|Correct the request before resending| |3161|Invalid Holder|Invalid card\_holder was sent in the request|Correct the request before resending| |3162|Cardholder is required|The card\_holder parameter was not included in the request|Correct the request before resending| |3181|COF purchase registration ID not found|Identifier of the COF purchase registration passed in the request was not found|Correct the request before resending| |3182|Duplicate COF purchase scheduled payment ID|Payment identifier for the COF purchase is duplicated|Correct the request before resending| |3183|COF purchase registration ID is invalidated due to card expiry date|Card for the specified COF purchase registration ID has expired|No actions required| |3184|COF purchase registration ID is cancelled|The COF purchase for the passed recurring\_id was canceled|Contact the technical support| |3186|Trigger operation ID is not found|Identifier of the debit operation that requires cancelling retry attempts was not found.|Correct the request before resending| |3190|Remittance payment method mismatched|Request payment method and the recipient account's payment method do not match|Correct the request before resending| |3191|Need clarification|Additional payment information submission is needed|Correct the request before resending| |3192|Remittance currency mismatched|Request currency and the recipient account's currency do not match|Correct the request before resending| |3193|Remittance is not allowed for this project|B2B remittances are not available for this project|Contact the technical support| |3194|Recipient ID is not found|Specified Recipient ID is not found|Correct the request before resending| |3195|Recipient ID is forbidden|B2B payment to the account with the specified Recipient ID is forbidden|Correct the request before resending| |3196|Remittance is not supported by payment system|The `remittance` payment type is not supported by the payment system|Contact the technical support| |3197|Remittance is not allowed for this payment method|The `remittance` payment type is not allowed for this payment method|Contact the technical support| |3198|Auto decline due to long verification|Operation was declined because the approval check by the AML specialists of Ecommpay timed out|Contact the technical support and try sending the request later| |3199|Operation was declined by AML checks|Operation was declined following the approval check by the AML specialists of Ecommpay|Contact your account manager| |3201|Expected error|Operation performing was rejected due to payment routing error|Contact the technical support| |3221|Card token not found|Token was not found in the request|Correct the request before resending| |3230|The operation with such merchant\_refund\_id already exists|Operation performing was rejected as the merchant refund ID passed in the request already exists in the payment platform|Correct the request before resending| |3241|Customer not found|Customer is not match the token in the request|Correct the request before resending| |3242|Account must be defined|Account object is required for this payment method|Correct the request before resending| |3243|Account must not be defined|Account object is disallowed for this payment method|Correct the request before resending| |3244|Bank id must be defined|Bank ID is required for this payment method|Correct the request before resending| |3261|Invalid signature|Invalid signature was sent in the request|Correct the request before resending| |3262|Empty signature|The value of the signature in the request is empty|Correct the request before resending| |3281|Converted amount is less than one minor unit|Converted amount is less than one minor currency unit|Contact the technical support| |3283|Refund amount more than init amount|Refund amount is more than initial amount|Correct the request before resending| |3284|Refund currency mismatched or empty|Refund currency mismatches or is empty|Correct the request before resending| |3285|Cannot make refund because of timeout block for repeat refund|The operation was rejected due to restrictions on the frequency of refund requests|Contact the technical support| |3286|The property amount is required|Missing amount in request. When passing the currency parameter, you must pass the amount parameter|Correct the request before resending| |3287|The property currency is required|The currency parameter in the request is missing. When passing the amount parameter, you must pass the currency parameter|Correct the request before resending| |3288|Refund prohibited on disputed transaction|Refund performing is prohibitedfor payments with chargebacks|Contact the technical support| |3289|The operation amount is less than fix fee of tariff|The operation was rejected because the amount is less than fix fee of tariff|Correct the request before resending| |3291|Incorrect merchant account settings for operation|The operation was rejected because only one operation type is allowed for the merchant account|Correct the request before resending| |3292|Online gambling payouts are not available for this MCC|Online gambling payouts are not available for this MCC|Contact the technical support| |3293|Payout method not filled in merchant account|Payout method not filled in merchant account|Contact the technical support| |3297|The provider's daily limit for the merchant account for the total amount of transactions has been exceeded|Operation was declined because the total amount of operations exceeds the daily limit imposed by the payment provider for the merchant account|Resend the request later| |3298|The provider's daily limit on the total amount of transactions has been exceeded|Operation was declined because the total amount of operations exceeds the daily limit imposed by the payment provider|Resend the request later| |3299|Sorry, the merchant status does not allow you to create an operation|Operation cannot be created for this merchant|Contact the technical support| |3301|Recurring registration is expired|Operation was rejected because a registered COF purchase associated with this ID has expired|Correct the request before resending| |3305|Payment Constraint 30-days Payout operations number exceeded for MCC 7995, 9406 Domestic|Operation performing was rejected due to exceeding the monthly operations limit on payouts for MCC 7995, 9406 Domestic|Resend the request later| |3306|Payment Constraint 30-days Payout operations number exceeded for MCC 7995, 9406 Cross-border|Operation performing was rejected due to exceeding the monthly limit operations on payouts for MCC 7995, 9406 Cross-border|Resend the request later| |3307|Payment Constraint 30-days Payout operations number exceeded for Money transfer Domestic|Operation performing was rejected due to exceeding the monthly operations limit on payouts for domestic money transfers|Resend the request later| |3308|Payment Constraint 30-days Payout operations number exceeded for Money transfer Cross-border|Operation performing was rejected due to exceeding the monthly operations limit on payouts for cross-border money transfers|Resend the request later| |3309|Payment Constraint 30-days Payout operations number exceeded for Funds disbursement Domestic|Operation performing was rejected due to exceeding the monthly operations limit on payouts for domestic funds disbursements|Resend the request later| |3310|Payment Constraint 30-days Payout operations number exceeded for Funds disbursement Cross-border|Operation performing was rejected due to exceeding the monthly operations limit on payouts for cross-border funds disbursements|Resend the request later| |3311|Payment Constraint Invalid Weekly Payout for MCC 7995, 9406 Domestic|Operation performing was rejected due to exceeding the weekly limit on payouts for MCC 7995, 9406 Domestic|Resend the request later| |3312|Payment Constraint Invalid Weekly Payout for MCC 7995, 9406 Cross-border|Operation performing was rejected due to exceeding the weekly limit on payouts for MCC 7995, 9406 Cross-border|Resend the request later| |3313|Payment Constraint Invalid Weekly Payout for Money transfer Domestic|Operation performing was rejected due to exceeding the `100 000 USD` weekly limit on payouts for domestic money transfers|Resend the request later| |3314|Payment Constraint Invalid Weekly Payout for Money transfer Cross-border|Operation performing was rejected due to exceeding the `100 000 USD` weekly limit on payouts for cross-border money transfers|Resend the request later| |3315|Payment Constraint Invalid Weekly Payout for Funds disbursement Domestic|Operation performing was rejected due to exceeding the `600 000 USD` weekly limit on payouts for domestic funds disbursements|Resend the request later| |3316|Payment Constraint Invalid Weekly Payout for Funds disbursement Cross-border|Operation performing was rejected due to exceeding the `250 000 USD` weekly limit on payouts for cross-border funds disbursements|Resend the request later| |3317|Payment Constraint Invalid 24 Hour Payout for MCC 7995, 9406 Domestic|Operation performing was rejected due to exceeding the daily limit on payouts for MCC 7995, 9406 Domestic|Resend the request later| |3318|Payment Constraint Invalid 24 Hour Payout for MCC 7995, 9406 Cross-border|Operation performing was rejected due to exceeding the daily limit on payouts for MCC 7995, 9406 Cross-border|Resend the request later| |3319|Payment Constraint Invalid 24 Hour Payout for Money transfer Domestic|Operation performing was rejected due to exceeding the `50 000 USD` daily limit on payouts for domestic money transfers|Resend the request later| |3320|Payment Constraint Invalid 24 Hour Payout for Money transfer Cross-border|Operation performing was rejected due to exceeding the `50 000 USD` daily limit on payouts for cross-border money transfers|Resend the request later| |3321|Payment Constraint Invalid 24 Hour Payout for Funds disbursement Domestic|Operation performing was rejected due to exceeding the `250 000 USD` daily limit on payouts for domestic funds disbursements|Resend the request later| |3322|Payment Constraint Invalid 24 Hour Payout for Funds disbursement Cross-border|Operation performing was rejected due to exceeding the `100 000 USD` daily limit on payouts for cross-border funds disbursements|Resend the request later| |3323|Payment Constraint Invalid 30-days Payout for MCC 7995, 9406 Domestic|Operation performing was rejected due to exceeding the monthly limit on payouts amount for MCC 7995, 9406 Domestic|Resend the request later| |3324|Payment Constraint Invalid 30-days Payout for MCC 7995, 9406 Cross-border|Operation performing was rejected due to exceeding the monthly limit on payouts amount for MCC 7995, 9406 Cross-border|Resend the request later| |3325|Payment Constraint Invalid 30-days Payout for Money transfer Domestic|Operation performing was rejected due to exceeding the `200 000 USD` monthly limit on payouts amount for domestic money transfers|Resend the request later| |3326|Payment Constraint Invalid 30-days Payout for Money transfer Cross-border|Operation performing was rejected due to exceeding the `200 000 USD` monthly limit on payouts amount for cross-border money transfers|Resend the request later| |3327|Payment Constraint Invalid 30-days Payout for Funds disbursement Domestic|Operation performing was rejected due to exceeding the `1 250 000 USD` monthly limit on payouts amount for domestic funds disbursements|Resend the request later| |3328|Payment Constraint Invalid 30-days Payout for Funds disbursement Cross-border|Operation performing was rejected due to exceeding the `500 000 USD` monthly limit on payouts amount for cross-border funds disbursements|Resend the request later| |3329|Payment Constraint Weekly payout operations number exceeded for MCC 7995, 9406 Domestic|Operation performing was rejected due to exceeding the weekly limit on payouts number for MCC 7995, 9406 Domestic|Resend the request later| |3330|Payment Constraint Weekly payout operations number exceeded for MCC 7995, 9406 Cross-border|Operation performing was rejected due to exceeding the weekly limit on payouts number for MCC 7995, 9406 Cross-border|Resend the request later| |3331|Payment Constraint Weekly payout operations number exceeded for Money transfer Domestic|Operation performing was rejected due to exceeding the weekly limit on payouts number for domestic money transfers|Resend the request later| |3332|Payment Constraint Weekly payout operations number exceeded for Money transfer Cross-border|Operation performing was rejected due to exceeding the weekly limit on payouts number for cross-border money transfers|Resend the request later| |3333|Payment Constraint Weekly payout operations number exceeded for Funds disbursement Domestic|Operation performing was rejected due to exceeding the weekly limit on payouts number for domestic funds disbursements|Resend the request later| |3334|Payment Constraint Weekly payout operations number exceeded for Funds disbursement Cross-border|Operation performing was rejected due to exceeding the weekly limit on payouts number for cross-border funds disbursements|Resend the request later| |3335|Payment Constraint 24 hour payout operations number exceeded for MCC 7995, 9406 Domestic|Operation performing was rejected due to exceeding the daily limit on payouts number for MCC 7995, 9406 Domestic|Resend the request later| |3336|Payment Constraint 24 hour payout operations number exceeded for MCC 7995, 9406 Cross-border|Operation performing was rejected due to exceeding the daily limit on payouts number for MCC 7995, 9406 Cross-border|Resend the request later| |3337|Payment Constraint 24 hour payout operations number exceeded for Money transfer Domestic|Operation performing was rejected due to exceeding the daily limit on payouts number for domestic money transfers|Resend the request later| |3338|Payment Constraint 24 hour payout operations number exceeded for Money transfer Cross-border|Operation performing was rejected due to exceeding the daily limit on payouts number for cross-border money transfers|Resend the request later| |3339|Payment Constraint 24 hour payout operations number exceeded for Funds disbursement Domestic|Operation performing was rejected due to exceeding the daily limit on payouts number for domestic funds disbursements|Resend the request later| |3340|Payment Constraint 24 hour payout operations number exceeded for Funds disbursement Cross-border|Operation performing was rejected due to exceeding the daily limit on payouts number for cross-border funds disbursements|Resend the request later| |3341|Payout was declined due to card constraints|Operation was declined due to issuer restrictions|Contact the technical support| |3355|Payment Constraint 24 hour operations number exceeded for same card|Operation performing was rejected due to exceeding the daily limit on operations number for the same card|Resend the request later| |3356|The operation is not allowed for this card|The payment is declined because payment operations are prohibited for this card|No action required| |3357|Payment Constraint 30-days operations number exceed for same card|Operation performing was rejected due to exceeding the monthly limit on operations number for the same card|Resend the request later| |3358|Operation amount is less than limit|Operation amount is less than allowed limit|Correct the request before resending| |3360|Payment amount cannot exceed 50 EUR for prepaid non-reloadable card|If the sender uses a prepaid non-reloadable card, the amount to be debited cannot exceed `50 EUR`|Correct the request before resending| |3362|Payment Constraint Invalid 30-days Payout for MCC 7995, 9406|Operation performing was rejected due to exceeding the `50 000 USD` monthly limit on payouts amount for MCC 7995, 9406|Resend the request later| |3363|Trace ID must be present in recurring payment and MIT|There was an error while processing the request|Contact the technical support| |3400|AFT Payment Constraint for Commercial cards|Operation was declined due to restrictions on using commercial cards by sender|Correct the request before resending| |3402|Payment Constraint 25000 USD Amount limit exceeded for MoneySend Funding Transaction by Consumer cards|Operation performing was rejected due to exceeding the `25 000 USD` limit on one MoneySend Funding Transaction for consumer cards|Correct the request before resending| |3403|Payment Constraint 50000 USD Amount limit exceeded for MoneySend Funding Transaction by Small business cards|Operation performing was rejected due to exceeding the `50 000 USD` limit on one MoneySend Funding Transaction for small business cards|Correct the request before resending| |3404|Payment Constraint 25000 USD Amount limit exceeded for MoneySend payout by Consumer cards|Operation performing was rejected due to exceeding the `25 000 USD` limit on one MoneySend payout for consumer cards|Correct the request before resending| |3406|Payment Constraint 50000 USD Amount limit exceeded for MoneySend payout by Small business cards|Operation performing was rejected due to exceeding the `50 000 USD` limit on one MoneySend payout for small business cards|Correct the request before resending| |3407|Payment Constraint Invalid 30-days MoneySend payout for Consumer cards|Operation performing was rejected due to exceeding the monthly `25 000 USD` limit on MoneySend payouts for consumer cards|Resend the request later| |3408|Payment Constraint Invalid 30-days MoneySend payout for Small business cards|Operation performing was rejected due to exceeding the monthly `50 000 USD` limit on MoneySend payouts for small business cards|Resend the request later| |3409|Payment Constraint 2500 USD Amount limit exceeded for MoneySend Funding Transaction by Consumer cards|Operation performing was rejected due to exceeding the `2 500 USD` limit on one MoneySend Funding Transaction for consumer cards|Correct the request before resending| |3410|Payment Constraint 2500 USD Amount limit exceeded for MoneySend payout by Consumer cards|Operation performing was rejected due to exceeding the `2 500 USD` limit on one MoneySend payout for consumer cards|Correct the request before resending| |3411|Payment cannot be made due to location of the sender's card issuer outside the Europe Region|The sender's card issuer must be located in the European region|Correct the request before resending| |3412|Payment Constraint 25000 USD Amount limit exceeded for MoneySend payout by Small business cards|Operation performing was rejected due to exceeding the `25 000 USD` limit on one MoneySend payout for small business cards|Correct the request before resending| |3413|Payment Constraint 25000 USD Amount limit exceeded for MoneySend Funding Transaction by Small business cards|Operation performing was rejected due to exceeding the `25 000 USD` limit on one MoneySend Funding Transaction for small business cards|Correct the request before resending| |3414|Payment Constraint 50000 USD Amount limit exceeded for MoneySend payout by Consumer cards|Operation performing was rejected due to exceeding the `50 000 USD` limit on one MoneySend payout for consumer cards|Correct the request before resending| |3415|Payment Constraint 100000 USD Amount limit exceeded for MoneySend payout by Small business cards|Operation performing was rejected due to exceeding the `100 000 USD` limit on one MoneySend payout for small business cards|Correct the request before resending| |3416|Payment Constraint 50000 USD Amount limit exceeded for MoneySend Funding Transaction by Consumer cards|Operation performing was rejected due to exceeding the `50 000 USD` limit on one MoneySend Funding Transaction for consumer cards|Correct the request before resending| |3417|Payment Constraint 100000 USD Amount limit exceeded for MoneySend Funding Transaction by Small business cards|Operation performing was rejected due to exceeding the `100 000 USD` limit on one MoneySend Funding Transaction for small business cards|Correct the request before resending| |3418|Payment Constraint 75000 USD Amount limit exceeded for MoneySend payout by Small business cards|Operation performing was rejected due to exceeding the `75 000 USD` limit on one MoneySend payout for small business cards|Correct the request before resending| |3419|Payment Constraint 75000 USD Amount limit exceeded for MoneySend Funding Transaction by Small business cards|Operation performing was rejected due to exceeding the `75 000 USD` limit on one MoneySend Funding Transaction for small business cards|Correct the request before resending| |3431|Money transfer is not possible for two identical cards|The sender's PAN matches the recipient's PAN|Correct the request before resending| |3432|The request must contain either the identifier of the saved card or complete card details|Both the saved card ID and complete card details have been passed in objects `sender` and/or `recipient`|Correct the request before resending| |3433|The request contains complete card details for both cards. This endpoint is for making a payment using saved card data only|Complete card details of both the sender and the recipient have been specified in the request. Note that this endpoint is intended only for sending requests to make payments using saved card data|Correct the request before resending| |3434|The sender's card expired|The card of the sender has expired|Correct the request before resending| |3435|The recipient's card expired|The card of the recipient has expired|Correct the request before resending| |3436|The sender's card is invalid|The sender's card specified in the request is invalid|Correct the request before resending| |3437|The recipient's card is invalid|The recipient's card specified in the request is invalid|Correct the request before resending| |3438|Saved sender card has no expiration date|The sender's card expiry date is needed to proceed|Correct the request before resending| |3439|The saved card has no expiration date|The card expiry date is needed to proceed|Correct the request before resending| |3450|Payment Constraint Invalid 24 Hour AFT for Money transfer Domestic|Operation performing was rejected due to exceeding the `100 000 USD` daily limit on AFT amount for domestic money transfers|Resend the request later| |3451|Payment Constraint Invalid Weekly AFT for Money transfer Domestic|Operation performing was rejected due to exceeding the `250 000 USD` weekly limit on AFT amount for domestic money transfers|Resend the request later| |3452|Payment Constraint Invalid 30-days AFT for Money transfer Domestic|Operation performing was rejected due to exceeding the `500 000 USD` monthly limit on AFT amount for domestic money transfers|Resend the request later| |3470|Payment was declined due to sender's card constraints|Operation performing was rejected due to the type of the sender's card|Contact the technical support| |3471|Payment was declined due to recipient's card constraints|Operation performing was rejected due to the type of the recipient's card|Contact the technical support| |3472|Payment was declined due to constraints in the region of the recipient card|Operation performing was rejected due to the region of the recipient's card issuer|Contact your key account manager| |3480|Payment cannot be made due to location of the sender's card issuer outside the EEA|The sender's card issuer cannot be located outside the EEA|Correct the request before resending| |3490|Required fields for Debt Repayment are missing|The required parameters for performing a debt repayment operation are not specified in the request|Correct the request before resending| |3491|Invalid card type for Debt Repayment|Invalid card type for performing a debt repayment operation|Correct the request before resending| |3606|Payment Constraint Invalid 30-days MoneySend Funding Transaction for Consumer cards|Operation performing was rejected due to exceeding the monthly amount limit on Moneysend Funding Transaction for consumer cards|Resend the request later, upon the expiration of the current 30-day period| |3607|Payment Constraint Invalid 30-days MoneySend Funding Transaction for Small business cards|Operation performing was rejected due to exceeding the monthly amount limit on Moneysend Funding Transaction for small business cards|Resend the request later, upon the expiration of the current 30-day period| |3609|Operation amount must be equal to the initial amount|Operation amount must be the same as the amount of the initial operation|Correct the request before resending| |3610|Refund unavailable for the current operation|Refund is prohibited for this operation|Contact the technical support| |3611|AFT reversal must be used to refund within the first 24 hours of the original AFT|This operation can be cancelled only within the first 24 hours after it was initially executed|Contact the technical support| |3612|One or more required money transfer fields are empty|Additional information about the sender and/or the recipient is required|Correct the request before resending| |3613|Duplicate operation|Operation rejected because an operation with the same customer ID and payment amount already exists|Resend the request later| |3617|Not allowed mcc for pan with product code = F2|Merchants using this MCC are not eligible for performing operations with this type of card \(product code F2\)|Contact the technical support| |3618|Payment Constraint 10000 USD Amount limit exceeded for MoneySend payout by Consumer cards|Operation performing was rejected due to exceeding the `10 000 USD` limit on one MoneySend payout for consumer cards|Correct the request before resendingYou can split the operation amount into several and send several requests with each amount not exceeding the limit | |3619|Payment Constraint 10000 USD Amount limit exceeded for MoneySend payout by Small business cards|Operation performing was rejected due to exceeding the `10 000 USD` limit on one MoneySend payout for small business cards|Correct the request before resendingYou can split the operation amount into several and send several requests with each amount not exceeding the limit | |3620|Payment Constraint 125000 USD Amount limit exceeded for MoneySend payout by Consumer cards|Operation performing was rejected due to exceeding the `125 000 USD` limit on one MoneySend payout for consumer cards|Correct the request before resendingYou can split the operation amount into several and send several requests with each amount not exceeding the limit | |3621|Payment Constraint 125000 USD Amount limit exceeded for MoneySend payout by Small business cards|Operation performing was rejected due to exceeding the `125 000 USD` limit on one MoneySend payout for small business cards|Correct the request before resendingYou can split the operation amount into several and send several requests with each amount not exceeding the limit | |3622|Payment Constraint 125000 USD Amount limit exceeded for MoneySend Funding Transaction by Consumer cards|Operation performing was rejected due to exceeding the `125 000 USD` limit on one MoneySend Funding Transaction for consumer cards|Correct the request before resendingYou can split the operation amount into several and send several requests with each amount not exceeding the limit | |3623|Payment Constraint 125000 USD Amount limit exceeded for MoneySend Funding Transaction by Small business cards|Operation performing was rejected due to exceeding the `125 000 USD` limit on one MoneySend Funding Transaction for small business cards|Correct the request before resendingYou can split the operation amount into several and send several requests with each amount not exceeding the limit | |3624|Payment Constraint 10000 USD Amount limit exceeded for MoneySend Funding Transaction by Consumer cards|Operation performing was rejected due to exceeding the `10 000 USD` limit on one MoneySend Funding Transaction for consumer cards|Correct the request before resendingYou can split the operation amount into several and send several requests with each amount not exceeding the limit | |3625|Payment Constraint 10000 USD Amount limit exceeded for MoneySend Funding Transaction by Small business cards|Operation performing was rejected due to exceeding the `10 000 USD` limit on one MoneySend Funding Transaction for small business cards|Correct the request before resendingYou can split the operation amount into several and send several requests with each amount not exceeding the limit | |3626|Payment Constraint Invalid 24 Hour payout for MoneySend by Consumer cards|Operation performing was rejected due to exceeding the daily limit on the number of payouts for consumer cards|Resend the request later, upon the expiration of the 24-hour period| |3627|Payment Constraint Invalid 24 Hour payout for MoneySend by Small business cards|Operation performing was rejected due to exceeding the daily limit on the number of payouts for small business cards|Resend the request later, upon the expiration of the 24-hour period| |3628|Payment Constraint Invalid 24 Hour funding for MoneySend by Consumer cards|Operation performing was rejected due to exceeding the daily limit on the number of funding operations for consumer cards|Resend the request later, upon the expiration of the 24-hour period| |3629|Payment Constraint Invalid 24 Hour funding for MoneySend by Small business cards|Operation performing was rejected due to exceeding the daily limit on the number of funding operations for small business cards|Resend the request later, upon the expiration of the 24-hour period| |3630|Payment Constraint Invalid Weekly payout for MoneySend by Consumer cards|Operation performing was rejected due to exceeding the weekly limit on the number of payouts for consumer cards|Resend the request later, upon the expiration of the current 7-day period| |3631|Payment Constraint Invalid Weekly payout for MoneySend by Small business cards|Operation performing was rejected due to exceeding the weekly limit on the number of payouts for small business cards|Resend the request later, upon the expiration of the current 7-day period| |3632|Payment Constraint Invalid Weekly funding for MoneySend by Consumer cards|Operation performing was rejected due to exceeding the weekly limit on the number of funding operations for consumer cards|Resend the request later, upon the expiration of the current 7-day period| |3633|Payment Constraint Invalid Weekly funding for MoneySend by Small business cards|Operation performing was rejected due to exceeding the weekly limit on the number of funding operations for small business cards|Resend the request later, upon the expiration of the current 7-day period| |3634|Payment Constraint Invalid 24 Hour for Payout mcc 7995, 9406 by Consumer cards|Operation performing was rejected due to exceeding the daily limit on the number of payouts for consumer cards applicable if the MCC is 7995 or 9406|Resend the request later, upon the expiration of the 24-hour period| |3635|Payment Constraint Invalid Weekly for Payout mcc 7995, 9406 by Consumer cards|Operation performing was rejected due to exceeding the weekly limit on the number of payouts for consumer cards applicable if the MCC is 7995 or 9406|Resend the request later, upon the expiration of the current 7-day period| |3900|Payment Constraint 50000 USD Amount limit exceeded for Money transfer|Operation performing was rejected due to exceeding the `50 000 USD` amount limit for money transfers|Correct the request before resending| |3901|Payment Constraint 25000 USD Amount limit exceeded for Money transfer|Operation performing was rejected due to exceeding the `25 000 USD` amount limit for money transfers|Correct the request before resending| |9999|Awaiting processing|Awaiting internal processing. Please wait|It is necessary to wait| ## Codes from Risk Control System \(RCS\) {#section_yrx_2ds_xzb .section} |Code|Message|Description|Action| |----|-------|-----------|------| |1401|RCS reject. PAN is Blacklisted in RCS|Card PAN is blacklisted in RCS|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1402|RCS reject. Customer is Blacklisted in RCS|Customer is blacklisted in RCS|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1403|RCS reject. Cardholder is Blacklisted in RCS|Cardholder is blacklisted in RCS|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1404|RCS reject. IIN is Blacklisted in RCS|Card IIN is blacklisted in RCS|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1405|RCS reject. IP is Blacklisted in RCS|Customer IP address is blacklisted in RCS|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1406|RCS reject. Email is Blacklisted in RCS|Customer email address is blacklisted in RCS|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1407|RCS reject. Phone is Blacklisted in RCS|Customer phone number is blacklisted in RCS|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1408|RCS reject. Card is compromised|Customer card is lost or stolen|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1409|RCS Reject. Interval too short|Operation frequency limit has been exceeded|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1410|RCS reject. Domain is forbidden|The customer's email domain is blacklisted in RCS|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1411|RCS reject. Country is forbidden|Operation processing is prohibited for this country|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1412|RCS reject. Country mismatch|Country mismatch for a customer|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1413|RCS reject. Country limit exceeded|The limit of countries from which operations were carried out has been exceeded|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1414|RCS Reject. Country is forbidden for cross-border transaction|AFT operation processing is prohibited for this country|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1415|RCS reject. Rejected by Scoring system|Operation is rejected because it was deemed suspicious by the scoring system|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1421|RCS reject. Invalid amount|The specified payment amount is out of range|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1422|RCS reject. Amount limit exceeded|Payment amount limit has been exceeded|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1431|RCS reject. Allowed number of cards exceeded|Allowed number of cards used for payment processing has been exceeded|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1432|RCS reject. Allowed number of emails exceeded|Allowed number of emails used for payment processing has been exceeded|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1433|RCS reject. Count limit exceeded|Operation count limit has been exceeded|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1434|RCS reject. Duplicate operation|High risk of duplicated operation|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1435|RCS reject. Allowed number of users exceeded|Allowed number of different identifiers for the customer has been exceeded|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1437|RCS reject. Allowed number of names exceeded|Exceeded the allowed number of different spellings of the customer name which are treated by the RCS as different cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1441|RCS reject. Rejected by compliance restriction|Rejected due to compliance restrictions|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1450|RCS reject. Rejected by sanctions lists|Rejected due to a match with one or several sanctions lists of cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1451|RCS reject. Rejected by AML restriction|Rejected as a result of an AML check|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1452|RCS reject. Rejected by AML UK sanction list|Rejected due to a match with the AML UK sanctions list of cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1453|RCS reject. Rejected by AML US sanction list|Rejected due to a match with the AML US sanctions list of cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1455|RCS reject. Rejected by AML phrase list|Rejected due to a match with the AML phrase list of cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1456|RCS reject. Rejected by holdername format validation|Rejected due to failing a cardholder name validation check|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1457|RCS reject. Rejected by AML EU sanction list|Rejected due to a match with the AML EU sanctions list of cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1458|RCS reject. Rejected by AML UN sanction list|Rejected due to a match with the AML UN sanctions list of cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1459|RCS reject. Rejected by AML NL sanction list|Rejected due to a match with the AML NL sanctions list of cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1460|RCS reject. Rejected by AML UAE sanction list|Rejected due to a match with the AML UAE sanctions list of cardholder names|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1461|RCS reject. Restricted card product code|Restricted card product code|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1462|RCS reject. Restricted card type|Restricted card type|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1463|RCS reject. Cardholder name mismatch|Cardholder name mismatch|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |1499|RCS reject. Machine Learning recommendation|Operation is rejected as suspicious following the assessment with the use of the artificial intelligence|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | ## Codes from external card payment systems {#section_h2j_fds_xzb .section} |Code|Message|Description|Action| |----|-------|-----------|------| |10000|General decline|Operation was declined by PSP for an unknown reason|Resend the request| |10100|Declined by external provider|Operation was declined by PSP without explanation|Resend the request| |10101|Decline due to amount or frequency limit|Operation was declined due to amount or frequency limitation|Correct the request before resending or resend the request later| |101011|Decline due to amount limit|Operation was declined due to limitation of amount|Correct the request before resending| |101012|Decline due to amount limit per period for the customer|Operation was declined due to limitation of payment amount per period for a customer|Resend the request later| |101013|Decline due to frequency limit|Operation was declined due to limitation of payment attempts frequency|Resend the request later| |101014|Too much declined operations per period for the customer|Operation was declined due to limitation of payment attempts frequency per period for a customer|Resend the request later| |10102|Incorrect data entered|Operation was declined due to incorrect card data entry|Correct the request before resending| |101021|Incorrect PAN|Operation was declined due to incorrect card PAN entry|Correct the request before resending| |10103|Incorrect PIN or CVV|Operation was declined due to incorrect PIN or CVV entry|Correct the request before resending| |10104|Incorrect 3DS password|Operation was declined due to incorrect 3DS password entry|Resend the request| |10105|Insufficient funds on card|Operation was declined due to insufficient funds on the card|Resend the request| |10106|Card expired|Operation was declined due to incorrect card expiry date entry|Correct the request before resending| |10107|Allowable PIN tries exceeded|Operation was declined due to multiple entry of incorrect PIN|Resend the request| |10108|Maestro MO/TO operation is prohibited for this country|Operation was declined due to a MO/TO payment is not allowed for the country in the request|Correct the request before resending| |10109|COF payment registration or customer payment data saving is not approved by external provider|COF payment registration or customer payment data saving is not approved by external provider|Resend the request later| |10110|Subscription is canceled by customer on the issuer side|Operation was declined because the customer cancelled the COF purchase|No required action necessary. You can also register a new COF purchase | |10112|Insufficient Funds. Retry later|Operation was declined due to insufficient funds on the card|Resend the request later| |10113|Insufficient Funds. Do not retry|Operation was declined due to insufficient funds on the card|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |10114|Declined by 3DS Check|Operation was declined following the 3‑D Secure authentication attempt|Resend the request later| |10201|Refer to card issuer|Operation was declined by the issuer|You can recommend your customer the following actions: - Refer to the issuer in order to determine the cause of the problem with the card and what can be done to solve it. - Use a different payment instrument to make a payment. | |10202|Issuer inoperative|Operation was declined due to the unavailability of the card issuer|Resend the request| |10203|Pick-up card|Operation was declined due to a special response from the bank that the card was compromised|No action required| |10204|Restrictions for the customer card|Operation was declined due to restrictions on the customer card. Contact the card issuer|Correct the request before resending| |10205|Not enrolled for 3DS|Operation was declined because the customer card does not support 3‑D Secure authentication|Correct the request before resending| |10206|Restrictions for the customer data|Operation performing for this customer was rejected by the external provider|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |10301|Operation was cancelled|Operation was cancelled by the participant|Resend the request| |10401|Declined by PSP risk system|Operation was declined by PSP risk department. Do not show this message to a customer|Correct the request before resending| |10402|Suspicious operation|Operation was declined by PSP anti-fraud system|No action required| |10403|Fraud/Security. Try again using 3DS authentication|Operation was declined by PSP anti-fraud system because the 3‑D Secure authentication is necessary|Complete the procedure of the 3‑D Secure authentication| |10404|Suspected fraud. Do not try again|Operation was declined by PSP anti-fraud system|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |10405|Fraud or closed account. Do not try again|Operation was declined by PSP anti-fraud system|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |10501|Refer to acquirer|Operation was declined due to incorrect interaction with PSP|Contact the technical support| |10502|Error during operation validation|Operation was declined during the operation data validation process|Correct the request before resending| |10503|Incorrect acquirer settings|Operation was declined due to incorrect settings. Contact the acquirer|Contact the technical support| |10504|Insufficient funds on acquirer balance|Operation was declined due to insufficient funds on the acquirer balance|Contact the technical support| |10505|PSP system is inoperative|Operation was declined due to the unavailability of PSP. Please try again later|Resend the request| |10601|Try again|Operation was declined. Please try again|Resend the request| |10602|Time-out|Operation was declined due to time-out. Please try again|Resend the request| |10603|Operation could not be authorized. Try again later|Operation could not be authorized now. Please try again later|Resend the request| |10701|Wrong requests sequence|Operation was declined due to incorrect sequence of requests|Correct the request before resending| |10702|Invalid request|Operation was declined due to malformed format of the request|Contact the technical support| |10703|Incorrect eci|Operation was declined due to incorrect ECI code received by the acquirer|Contact the technical support| |10704|Card holder not found|Operation was declined because the acquirer requires a cardholder parameter|Contact the technical support| |10705|The request contains no fields of the customer object|Operation was declined due to insufficient customer data requested by the acquirer|Contact the technical support| |10706|Refund unavailable for current operation|Refund operation was declined by acquirer as it is unavailable|Contact the technical support| |10707|Required rental information is not present|Operation was declined due to insufficient rental information|Contact the technical support| |10708|Required flight details is not present|Operation was declined due to insufficient flight details|Contact the technical support| |10709|Additional customer 3‑D Secureauthentication required|Operation was declined by issuer as the customer did not passed the 3‑D Secure authentication. Please contact the card issuer|Contact the technical support| |10722|Strong Customer Authentication mandated according to PSD2|Operation was declined since it was not authenticated in accordance with the SCA \(Strong Customer Authentication\) requirements|Contact the technical support| |10801|External provider approved but did not process the operation|External provider approved but did not process the operation|Contact the technical support| |10805|Life cycle \(Mastercard use only\)|Operation was declined by issuer due to incorrect entry of card expiry date or card number|Try to correct the request before resending| |10806|Policy \(Mastercard use only\)|Operation was declined by issuer|Please contact the technical support| |10807|Fraud/Security|Operation was declined by issuer due to suspicion of fraud|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |10810|Life cycle. Do not try again|Operation was declined by the issuer due to incorrect entry of card expiry date or card number|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |10811|Policy. Do not try again|Operation was declined by the issuer|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |10812|Invalid card. Do not try again|Operation was declined by the issuer|No required action necessary. You can also contact the technical support to find out what else can be done in this situation | |19999|Awaiting processing|Awaiting external processing of the request. Please wait|It is necessary to wait| ## Codes from external alternative payment systems {#section_uxt_fds_xzb .section} |Code|Message|Description|Action| |----|-------|-----------|------| |20000|General decline|Operation was declined for an unknown reason|Resend the request| |20100|Declined by external provider|Operation was declined by PSP without explanation|Resend the request| |20101|Decline due to amount or frequency limit|Operation was declined due to limitation of amount or frequency|Correct the request before resending or resend the request later| |201011|Decline due to amount limit|Operation was declined due to limitation of amount|Correct the request before resending| |201012|Decline due to amount limit per period for the customer|Operation was declined due to limitation of payment amount per period for a customer|Resend the request later| |201013|Decline due to frequency limit|Operation was declined due to limitation of payment attempts frequency|Resend the request later| |201014|Too much declined operations per period for the customer|Operation was declined due to limitation of payment attempts frequency per period for a customer|Resend the request later| |20102|Incorrect account data entered|Operation was declined due to incorrect account data entry|Correct the request before resending| |20103|Incorrect login or password|Operation was declined due to incorrect customer login or password entry|Correct the request before resending| |20104|Password attempts entry exceeded|Operation was declined due to multiple entry of incorrect password|Resend the request| |20105|Insufficient funds on customer account|Operation was declined due to insufficient funds on the customer account|Resend the request| |20106|Customer account is no longer available|Operation was declined due to the customer account is expired or unavailable|Correct the request before resending| |20107|Customer account does not support requested currency|Operation was declined due to the customer account does not support requested currency|Correct the request before resending| |20109|COF payment registration or customer payment data saving is not approved by external provider|COF payment registration or customer payment data saving is not approved by external provider|Resend the request later| |20110|Subscription is canceled by customer on the issuer side|Subscription is canceled by customer on the issuer side|No action required| |20111|Operation declined by PSP because the Direct Debit mandate is inactive, cancelled, or expired|Operation declined by PSP because the Direct Debit mandate is inactive, cancelled, or expired|No action required| |20201|Restrictions for the customer account|Operation was declined due to restrictions on customer account. Contact the PSP|Correct the request before resending| |20202|PSP system is unavailable|Operation was declined due to the unavailability of PSP. Please try again later|Resend the request| |20203|Compromised customer account|Operation was declined due to a special response from the bank: customer account was compromised|No action required| |20204|Crediting this customer account is blocked|Operation was declined. The customer account is not allowed to perform crediting. Contact the PSP|Correct the request before resending| |20205|Payment method is not available for customer country|Payment method is not available for customer country|No action required| |20206|Difficulties on the mobile operator side|Operation was declined due to the technical problems on the mobile operator side|Resend the request later| |20301|Account owner cancelled operation|Operation was declined by the account owner|Resend the request| |20302|Unacceptable password|Password does not meet the requirements. Please try another|Correct the request before resending| |20303|Customer is not permitted to perform the action|Request is prohibited due to lack of permits|Correct the request before resending| |20304|Incorrect amount paid|Operation was declined due to incorrect amount paid by a customer|Resend the request| |20401|Declined by PSP risk system|Operation was declined by PSP risk department. Do not show this message to a customer|Correct the request before resending| |20402|Suspicious operation|Operation was declined by PSP anti-fraud system|No action required| |20450|The Verification of Payee cannot be performed due to technical reasons.|The initiated Verification of Payee cannot be carried out due to errors in the interaction between the platform and the provider service|Resend the request in several minutes.If the error persists, contact the technical support | |20451|Payout or refund cannot be processed based on the Verification of Payee result.|The initiated operation cannot be processed due to the discrepancy between the final Verification of Payee status and one of the approved algorithms \([details](en_verification_of_payee.md#)\)|You can notify the customer about the spelling discrepancy between the specified name and the account holder's name and offer to try again, clarifying the name.If the error persists, contact the technical support | |20501|Refer to acquirer|Operation was declined due to incorrect interaction with PSP|Contact the technical support| |20502|Error during operation validation|Operation was declined during the operation validation process|Correct the request before resending| |20503|Incorrect acquirer settings|Operation was declined due to incorrect settings. Contact the acquirer|Contact the technical support| |20504|Insufficient funds on acquirer balance|Operation was declined due to insufficient funds on the acquirer balance|Contact the technical support| |20601|Try again|Operation was declined. Please try again|Resend the request| |20602|Time-out|Operation was declined due to time-out. Please try again|Resend the request| |20603|Operation could not be authorized. Try again later|Operation cannot be authorized now. Please try again later|Resend the request| |20604|Notification is not delivered|Operation was declined. Notification cannot be delivered|Contact the technical support| |20701|Wrong requests sequence|Operation was declined due to incorrect sequence of requests|Correct the request before resending| |20702|Invalid request. Try again|Operation was declined due to malformed format of the request|Contact the technical support| |20703|Invoice not found|Operation was declined. Invoice was not found in the system|Contact the technical support| |20705|Merchant account is blocked|Operation was declined due to the merchant’s account being blocked|Contact the technical support| |20706|Operation not supported by provider|Operation was declined because the provider does not support this type of operation|Contact the technical support| |20801|Payment provider approved but did not process the operation|Payment provider approved but did not process the operation|Contact the technical support| |20802|The payment provider did not confirm neither successful nor negative status of the payment transaction|The payment provider cannot confirm status of the payment|It is necessary to wait| |20812|The service provider did not confirm the account crediting|The operation was declined because the payment service provider did not confirm that the funds were deposited to the bank account of the customer|Resend the request| |20899|The payment is processed on the provider side. It can take up to several days. Inform customer if needed|The payment is processed on the provider or payment system side. It can take up to several days. Inform the customer if needed|No additional interactions with the platform are required| |29999|Awaiting processing|Awaiting external processing. Please wait|It is necessary to wait| ## Codes from merchants {#section_im2_gds_xzb .section} |Code|Message|Description|Action| |----|-------|-----------|------| |30000|Operation was declined by merchant|Operation processing was declined by merchant|No action required| |30100|Operation was declined by merchant for an unknown reason|Operation processing was declined by merchant for an unknown reason|No action required| |30301|Merchant did not confirm operation processing|Operation processing was not confirmed by merchant|No action required| |30302|Merchant did not respond during the operation confirmation process|Merchant did not respond during the operation confirmation process|No action required| |30303|The amount or currency confirmed by the merchant is different from the requested one|The amount or currency confirmed by the merchant is different from one in the request|No action required| |30401|Empty draws list|The list of amounts available for payment is empty|No action required| **Parent topic:**[Handling payment processing information](en_platform_payment_information.md) --- # Payment Page {#en_PP_about .concept} A section with the information about working with the payment form. This section provides the information about working with the Payment Page payment form. ## Overview {#section_tjy_s2b_dbb .section} This article introduces the information about the payment form, the general workflow of using the form, and the capabilities overview—[Overview](en_PP_general.md#). ## Integration {#section_xqb_k5g_btb .section} The information about setting up Payment Pagein different cases: - [Quickstart](en_pp_quickstart.md#)—about quick and easy ways to organise payment processing with the application of ready-to-use solutions, such as SDKs and source code examples, to their fullest extent. - [Interaction concepts](en_pp_interaction_organisation.md#)—about organising the work with Payment Page on the web service side in various cases based on the principles of the payment platform operation. - [Integration using SDK](en_sdk_overview.md)—about using SDKs for mobile applications anddata signing. - [Integration using plug-ins](en_CMS.md)—about embedding the payment form into the websites on the basis of various CMSs and specialised platforms with the help of plug-ins. - [Using Payment Page in embedded mode for card payments](en_pp_microframe_solution.md)—about using Payment Page embedded mode edition to accept standard card payments. - [Using embedded buttons for Apple Pay and Google Pay payments](en_pp_embedded_payment_buttons.md#)—about embedding branded payment buttons into the web service to process express checkout payments, with the support for collecting customer information and providing shipping details in the services of Apple Pay and Google Pay. ## UX configuration {#section_m4b_k5g_btb .section} The information about various options of the payment form UX configuration: - [Options for opening Payment Page](en_PP_Integration.md)—about the ways of opening the form, including its opening in a separate tab, modal window, and an iframe object. - [Options for redirecting customers to third-party services](en_PP_pm_redirect_mode.md)—about the ways of opening auxiliary pageswhen working with different payment methods. - [Options for redirecting customers to the web service](en_PP_redirect_modes.md#)—about the ways of redirecting customers from the payment form to the web service via the specified URLs. ## Basic actions {#section_ywk_z5g_btb .section} The information about the basic actions that can be performed via the payment form: - [Purchase processing](en_pp_purchase.md)—about processing purchases that result in immediate debiting of funds. - [Authorisation hold](en_pp_purchase_auth.md)—about placing a hold on funds within a two-step purchase. - [COF purchase registration](en_pp_recurring.md)—about registering purchases followed by a series of recurring debits. - [Performing payouts](en_pp_payout.md)—about issuing payouts. - [Payment instrument verification](en_pp_account_verification.md)—about debiting of a zero amount or placing a hold on funds for validating the payment instrument. - [Tokenization](en_pp_token.md)—about opening the payment form for registering payment data and forming a token for this data. ## Additional capabilities {#section_ejc_nvg_btb .section} The information about various capabilities for boosting payment acceptance rates, customer convenience, and the quality of the provided services—[Auxiliary procedures and additional capabilities](en_PP_Additional.md#)and [Customisation](en_PP__design_customisation.md#). ## Technical aspects {#section_jkz_2ml_pjc .section} The information about various technical aspects of working with program requests—[Payment Page API specification](en_PP_Parameters.md). - **[Overview](en_PP_general.md#)** An article with the introductory information about Payment Page, the general workflow of using the form, and the overview of its capabilities. - **[Quickstart](en_pp_quickstart.md#)** A quickstart guide on how to implement payment processing via Payment Page with the use of SDKs and source code examples. - **[Interaction concepts](en_pp_interaction_organisation.md#)** An article about organising the work with Payment Page on the web service side based on the principles of the payment platform operation. - **[Integration using SDK](en_sdk_overview.md)** Articles about using SDKs for integrating Payment Page in mobile applications and for data signing. - **[Integration using plug-ins](en_CMS.md)** Articles about using plug-ins for embedding Payment Page into websites powered by various CMS and specialised platforms. - **[Using Payment Page in embedded mode for card payments](en_pp_microframe_solution.md)** An article about using Payment Page embedded mode edition to accept standard card payments. - **[Using embedded buttons for Apple Pay and Google Pay payments](en_pp_embedded_payment_buttons.md#)** An article about using a specialised version of Payment Page that enables seamless, native-style integration of the Apple Pay and Google Pay services. - **[UX configuration](en_pp_ux_configuration.md)** Articles about the primary workflows for the standard version of Payment Page, including options for opening it, handling redirects to third-party services and back to the web service, and managing these processes. - **[Basic actions](en_pp_basic_actions.md)** Articles about the core actions that can be performed via the payment form, with the description of user scenarios and relevant request and callback formats for standard card payments. - **[Auxiliary procedures and additional capabilities](en_PP_Additional.md)** Articles about auxiliary procedures and additional capabilities of Payment Page for boosting payment acceptance rates, customer convenience, and the quality of the provided services. - **[Customisation](en_PP__design_customisation.md#)** An article about the capability of customising the appearance of the payment form with the use of the Payment Page Designer in the Dashboard interface. - **[Payment Page API specification](en_PP_Parameters.md)** An API specification with the description of data structures used in requests for opening Payment Page. --- # Integration using SDK {#en_sdk_overview} Articles about using SDKs for integrating Payment Page in mobile applications and for data signing. ## SDKs for mobile applications {#section_okr_hxv_tvb .section} You can use specialised software development kits \(SDKs\) to accept in-app payments for processing via the Ecommpay payment platformwithout redirection to mobile browsers to open the payment form. These SDKs provide you with the functionality that allows exchanging all necessary data between the application client and the payment platform. They also allow you to utilise different user interfaces: SDK UI & Core includes interface components developed by Ecommpay while SDK Core allows you to use your in-house interface components. At present, the following versions of the mobile SDKs are available: | |![](images/universal/pr_lang_logos/android.svg)|![](images/universal/pr_lang_logos/apple.svg)| |--|-----------------------------------------------|---------------------------------------------| |**UI & Core** with the user interface by Ecommpay | for Android 5.0 and later - [native SDK](en_sdk_ui_and_core_android.md#) - [SDK for Flutter 3.3.0 and later](en_sdk_flutter.md#) - [SDK for React Native 0.75.3 and later](en_sdk_react_native.md#) | for iOS 15.6 and later - [native SDK](en_sdk_ui_and_core_ios.md#) - [SDK for Flutter 3.3.0 and later](en_sdk_flutter.md#) - [SDK for React Native 0.75.3 and later](en_sdk_react_native.md#) | |**Core** when you use your in-house user interface | [for Android 5.0 and later](en_sdk_core_android.md#) | [for iOS 11.0 and later](en_sdk_core_ios.md#) | If you have any questions regarding the specifics of working with the mobile SDKs or suggestions as to how their functionality can be expanded and enhanced, contact your Ecommpay account manager. With questions about the integration, testing, and use of these SDKs, contact the technical support. ## SDKs for data signing {#section_vcj_5zv_tvb .section} You can use specialised software development kits \(SDKs\) to work with digital signatures essential for program interaction with the Ecommpay payment platform. These SDKs allow you to sign data sets included in requests and verify the correctness of signatures in responses and callbacks sent by the platform \(to learn more about these algorithms, see [Signature generation and verification](en_platform_signature.md#)\). Implementing such SDKs implies using the secret signing keys provided by Ecommpay specifically for each project. Therefore, SDKs for data signing should be used on the server side of web services with proper security measures taken. At present, the following language-specific SDKs are available for data signing: - [C\#](en_sdk_net.md) using .NET 6.0 and later - [Go](en_sdk_go.md) 1.8 and later - [Java](en_sdk_java.md) using JDK 8 and later - [JavaScript](en_sdk_javascript.md) using Node.js 4.x - [PHP](en_sdk_php.md) 7.0 and later - [Python](en_sdk_python.md) 3.5 and later If you have any questions regarding the specifics of working with the SDKs for data signing or suggestions as to how their functionality can be expanded and enhanced, contact your Ecommpay account manager. With questions about the integration, testing, and use of these SDKs, contact the technical support. - **[SDK UI & Core for Android](en_sdk_ui_and_core_android.md#)** An article about using SDK UI & Core for integrating Payment Page with the interface from Ecommpay in Android mobile applications. - **[SDK UI & Core for iOS](en_sdk_ui_and_core_ios.md#)** An article about using SDK UI & Core for integrating Payment Page with the interface from Ecommpay in iOS mobile applications. - **[SDK Flutter for Android and iOS](en_sdk_flutter.md#)** An article about using SDK Flutter for integrating Payment Page in Android and iOS mobile applications. - **[SDK React Native for Android and iOS](en_sdk_react_native.md#)** An article about using SDK React for integrating Payment Page in Android and iOS mobile applications. - **[SDK Core for Android](en_sdk_core_android.md#)** An article about using SDK Core for integrating Payment Page with the option to use the in-house interface in Android mobile applications. - **[SDK Core for iOS](en_sdk_core_ios.md#)** An article about using SDK Core for integrating Payment Page with the option to use the in-house interface in iOS mobile applications. - **[SDK for C\# on the .NET platform](en_sdk_net.md)** An article about using data signing SDKs for web services developed in C\# for .NET. - **[SDK for Go](en_sdk_go.md)** An article about using data signing SDKs for web services developed in Go. - **[SDK for Java](en_sdk_java.md)** An article about using data signing SDKs for web services developed in Java. - **[SDK for JavaScript](en_sdk_javascript.md)** An article about using data signing SDKs for web services developed in JavaScript. - **[SDK for PHP](en_sdk_php.md)** An article about using data signing SDKs for web services developed in PHP. - **[SDK for Python](en_sdk_python.md)** An article about using data signing SDKs for web services developed in Python. **Parent topic:**[Payment Page](en_PP_about.md) --- # SDK for C\# on the .NET platform {#en_sdk_net} An article about using data signing SDKs for web services developed in C\# for .NET. ## Overview {#section_a2f_lpl_m5b .section} SDK for C\# on the .NET platform is a software development kit for ensuring the interaction of the web services developed in C\# with the Ecommpay payment platform during the processing of purchases via Payment Page. SDK for C\# on the .NET platform is used for signing the parameter set, generating the request for opening Payment Page, verifying callbacks received from Ecommpay, and obtaining payment information from the callbacks. SDK for C\# on the .NET platform from Ecommpay includes the library source code and other auxiliary files. SDK for C\# on the .NET platform is compatible with .NET version 6.0 or later and can be downloaded at the following URL: [https://github.com/ITECOMMPAY/paymentpage-sdk-net](https://github.com/ITECOMMPAY/paymentpage-sdk-net). ## Setup {#section_rkn_gql_m5b .section} To use SDK for C\# on the .NET platform, proceed as follows: 1. Address the following organisational issues of interaction with Ecommpay: 1. If the company has not obtained a project identifier and a secret key for interacting with the Ecommpay payment platform, submit[the application](https://ecommpay.com/apply-now/) for connecting to the payment platform. 2. If the company has obtained a project identifier and a secret key for interacting with the Ecommpay payment platform, inform the technical support specialists about the company's intention to integrate by using SDK for C\# on the .NET platform and coordinate the procedure of launching the functionality. 2. Install the library that is included in SDK for C\# on the .NET platform and link it into the code. ```language-csharp using ECommPay.PaymentPage.SDK; ``` 3. Modify the code for using the necessary functionality. 4. Coordinate with the Ecommpay technical support specialists the procedures and dates of integrating and launching the solution. The questions about working with SDK for C\# on the .NET platform, if any, should be directed to the Ecommpay technical support specialists. ## Payment form opening {#section_aj3_h5l_m5b .section} To open the payment form with the help of SDK for C\# on the .NET platform, proceed as follows: 1. Ensure that the library included in SDK for C\# on the .NET platform is linked into the web service source code. 2. Create an object of the `Payment` class and specify the values of the payment parameters. ```language-csharp dynamic payment = new Payment(, ""); // Project and payment identifiers unique within the project payment.payment_amount = 1001; // Payment amount in minor currency units payment.payment_currency = "EUR"; // Currency code in the format of ISO-4217 alpha-3 payment.customer_id = "customer_112"; // Customer identifier payment.payment_description = "Test payment"; // Payment description (optional parameter) ``` All parameters in this example, except for the payment description, are mandatory for any purchase. You may also need to pass other parameters, for example, the customer's email or phone number when the 3‑D Secure authentication is required. Such parameters must be specified as follows. ```language-csharp payment.customer_phone = "The customer's phone number. Must have from 4 to 24 digits"; payment.customer_email = "The customer's email"; ``` In addition, for card purchases you are recommended to pass the customer's billing address information: the country code in ISO 3166-1 alpha-2 \([details](en_country_codes.md)\), the postal code, the city, and the street address. Such parameters are specified as follows. ```language-csharp payment.billing_postal = "The postal code of the customer's billing address"; payment.billing_country = "The country of the customer's billing address, in ISO 3166-1 alpha-2"; payment.billing_city = "The city of the customer's billing address"; payment.billing_address = "The street of the customer's billing address"; ``` You can also use any other optional parameters available for working with Payment Page \(for more information, see [Payment Page API specification](en_PP_Parameters.md)\). 3. Create an object of the `Gate` class and specify the secret key value received from Ecommpay. This is necessary for automatic signature generation. ```language-csharp var gate = new Gate(''); // Secret key received from Ecommpay ``` 4. Generate the URL for opening the payment form. ```language-csharp var paymentUrl = gate.GetPurchasePaymentPageUrl(payment); ``` A correct URL for opening the payment form contains the signature and the payment parameters. ```language-xml https://paymentpage.ecommpay.com/payment?signature=OEKRlLXKStyoH%2BM 36hokUzLZsuB2gO8JALVnyevcV59akRi29elbheVscAEl0ljcoQVXDE390MwgWg%3D%3D&payment_id=TEST_1555 943554067... ``` 5. Use the generated URL for opening the payment form \([details](en_PP_Integration.md)\). ```language-csharp namespace MyProject; using ECommPay.PaymentPage.SDK; public class Example { /// /// Project identifier received from Ecommpay /// private const int ProjectId = 0; /// /// Secret key received from Ecommpay /// private const string SecretKey = "secret"; /// /// Return of the URL for payment form opening /// /// public static string GetUrl() { var paymentId = "test_payment"; // Payment identifier unique within the project dynamic payment = new Payment(ProjectId, paymentId); // Creation of the Payment object payment.payment_amount = 1001; // Payment amount in minor currency units payment.payment_currency = "EUR"; // Payment currency code in the format of ISO-4217 alpha-3 payment.customer_id = "customer_112"; // Customer identifier payment.payment_description = "Test payment"; // Payment description var gate = new Gate(SecretKey); // Creation of the Gate object return gate.GetPurchasePaymentPageUrl(payment); // Return of the URL for payment form opening } } ``` ## Callback processing {#section_okm_rvl_m5b .section} A callback is an HTTP-POST request that contains payment information in the format of a JSON string. During the work with SDK for C\# on the .NET platform, the information from the callbacks can be obtained with the help of the following methods: - `getPaymentId()`—returns the payment identifier. - `getPaymentStatus()`—returns the current payment status. - `getPayment()`—returns all payment information received in the callback. To obtain payment information via these methods, proceed as follows: 1. Ensure that the library included in SDK for C\# on the .NET platform is linked into the web service source code. 2. If an object of the `Gate` class was not created during the generation of the request for Payment Page opening—create this object and specify the secret key value received from Ecommpay. ```language-csharp var gate = new Gate(''); ``` 3. Create an object of the `Callback` class by using the JSON string that contains the payment information and was received in the callback from the Ecommpay payment platform. ```language-csharp try { var callback = gate.HandleCallback(data); // Receiving the data verification result } catch (ValidationException e) // Processing possible exceptions { Console.WriteLine(e); // Displaying the error message } ``` 4. Use the necessary method. ```language-csharp callback.get_payment_id() // Receiving the payment identifier callback.get_payment_status() // Receiving the current payment status callback.get_payment() // Receiving all payment information ``` If SDK for C\# on the .NET platform is used, the verification of the signature from the callback is performed automatically. ```language-csharp namespace MyProject; using ECommPay.PaymentPage.SDK; public class Example { /// /// Secret key received from Ecommpay /// private const string SecretKey = "secret"; /// /// Callback processing /// /// JSON string received in the notification. /// true in case of successful callback processing and false in other cases public bool Handler(string data) { var gate = new Gate(SecretKey); // Creation of the Gate object ICallback callback; // Attempt to receive the processed data try { // Receiving the verification result in the form of the Callback object callback = gate.HandleCallback(data); } // Processing possible exceptions catch (SdkException e) { Console.WriteLine(e); // Displaying the error message return false; } // Receiving the Payment object using its identifier // var order = OrderRepository.Get(callback.GetPaymentId()); // Changing the payment status according to the one received in the callback // order.SetStatus(callback.GetPaymentStatus()); // Saving the changes // order.Save(); return true; } } ``` ## Related topics {#section_j3l_hyl_m5b .section} - [Handling callbacks](en_platform_callbacks.md#) - [Payment processing](en_platform_payment_model.md) **Parent topic:**[Integration using SDK](en_sdk_overview.md) --- # SDK for Go {#en_sdk_go} An article about using data signing SDKs for web services developed in Go. SDK for Go is a software development kit for development of web services which are capable of integrating with the Ecommpay payment solutions to perform purchases by using Payment Page. This section describes how to use SDK for Go to build purchase experience from inside of your web service. SDK for Go is compatible with Go version 1.8 or later.You can download SDK for Go from Git: [https://github.com/ITECOMMPAY/paymentpage-sdk-go](https://github.com/ITECOMMPAY/paymentpage-sdk-go). ## What can I do with SDK for Go? {#section_mdv_1pf_nhb .section} SDK for Go allows you to do the following: - Calculate signature and generate an URL for opening the Payment Page. - Check callback signatures and extract payment details from callbacks. ## What's inside? {#section_myx_rk2_phb .section} SDK for Go contains the libraries for development and automated testing, as well as the service files. ## Using SDK for Go {#section_ow5_sdb_mhb .section} To start using SDK for Go you need to complete the following tasks: 1. Make sure you have ready your merchant ID and secret key obtained from Ecommpay. 1. If your company has never obtained any ID or secret key from Ecommpay, you need to submit an applicationat [https://ecommpay.com/apply-now/](https://ecommpay.com/apply-now/) for connecting to the Ecommpay payment platform. 2. If your company already has an ID and a secret key to sign messages obtained from Ecommpay, you need to notify the Ecommpay technical support specialists that you want to use SDK for Go and consult the customer support on how to arrange a test run. 2. Integrate the Ecommpay payment solution in your web service: 1. Install the SDK for Go libraries into a directory inside your web service project. 2. Import the libraries you need into your web service application. 3. Test and put your web service in production mode. 1. Request test card numbers and test project ID from Ecommpay, debug and test your web service. 2. Once testing is complete, request your production project ID from Ecommpay and put your web service in production mode. With any questions regarding the use of SDK for Go, contact the Ecommpay technical support specialists at [support@ecommpay.com](mailto:support@ecommpay.com). ## Installing and importing libraries {#section_y13_j32_nhb .section} You can install the SDK for Go libraries manually or by using automated procedures supported by the development environment you use. The following steps describe how to manually install the SDK for Go libraries. 1. If no $GOPATH environment variable is set, you need to set one. The $GOPATH is used to specify directories outside of $GOROOT that contains the source for Go projects and their binaries. 2. Run the following command in the command line of your operating system: ```language-php go get github.com/ITECOMMPAY/paymentpage-sdk-go ``` The command downloads the SDK for Go libraries in the $GOPATH directory to enable you to use all the classes provided by the libraries. 3. Import the SDK for Go into your web service source code in `import` section by running the following command: ```go import "github.com/ITECOMMPAY/paymentpage-sdk-go" ``` ## Opening payment form {#section_bty_ryn_lhb .section} A URL for opening Payment Page consists of a set of parameters, which are signed to secure the data transmitted to the Ecommpay payment platform. SDK for Go allows you to seamlessly sign parameters and generate URLs. To open the Payment Page payment form by using SDK for Go do the following: 1. Create an instance of the `payment` class and specify payment details. ```language-php payment := paymentpage.NewPayment(186, "TEST_1555943554067") // Project ID and payment ID, must be unique within your project scope payment.SetParam(paymentpage.ParamPaymentCurrency, "EUR") // Currency in the ISO-4217 alpha-3 format payment.SetParam(paymentpage.ParamPaymentAmount, 1000) // Amount in minor currency units payment.SetParam(paymentpage.ParamCustomerId, "customer_122") // Customer ID payment.SetParam(paymentpage.ParamPaymentDescription, "Test payment") // Payment description (optional) ``` All parameters in this example, except for the payment description, are mandatory for any purchase.You may also need to pass other parameters, for example, the customer's email or phone number when the 3‑D Secure authentication is required. Such parameters must be specified as follows. ```language-php payment.SetParam(paymentpage.ParamCustomerPhone, "The customer's phone number. Must have from 4 to 24 digits") payment.SetParam(paymentpage.ParamCustomerEmail, "The customer's email") ``` In addition, for card purchasesyou are recommended to pass the customer's billing address information: the country code in ISO 3166-1 alpha-2 \([details](en_country_codes.md)\), the postal code, the city, and the street address. Such parameters are specified as follows. ```language-php payment.SetParam(paymentpage.ParamBillingPostal, "The postal code of the customer's billing address") payment.SetParam(paymentpage.ParamBillingCountry, "The country of the customer's billing address, in ISO 3166-1 alpha-2") payment.SetParam(paymentpage.ParamBillingCity, "The city of the customer's billing address") payment.SetParam(paymentpage.ParamBillingAddress, "The street of the customer's billing address") ``` You can also use any other optional parameters available for Payment Page. For more information about the Payment Page invocation parameters, see [Payment Page API specification](en_PP_Parameters.md). 2. Create a `gate` instance and initiate it with the secret key you obtained from the Ecommpay technical support specialists. The secret key is required to sign parameters. ```language-php gate := paymentpage.NewGate("<*secret\_key*>") // Secret key you obtained from the technical support service ``` 3. Generate the URL for opening the payment form: ```language-php paymentPageUrl := gate.GetPaymentPageUrl(*payment) ``` The URL must contain payment parameters and signature \(abbreviated\): ```language-php https://paymentpage.ecommpay.com/payment?signature=OEKRlLXQsa2.. ..gWg%3D%3D&payment_id=pid_1555943554067... ``` 4. Use the generated URL for opening the payment form \([details](en_PP_Integration.md)\). Here is an example of generating a URL for opening a payment form in English.The payment method selection page includes detailed payment information including amount, currency, and short payment description. ```language-php payment := paymentpage.NewPayment(186, "test_payment_id") // Project ID and payment ID, must be unique within your project scope payment.SetParam(paymentpage.ParamPaymentAmount, 1000) // Amount in minor currency units payment.SetParam(paymentpage.ParamPaymentCurrency, "EUR") // Currency in the ISO-4217 alpha-3 format payment.SetParam(paymentpage.ParamCustomerId, "customer_122") // Customer ID payment.SetParam(paymentpage.ParamPaymentDescription, "Test payment") // Payment description (optional) payment.SetParam(paymentpage.ParamLanguageCode, "en") // Language code to use in payment form gate := paymentpage.NewGate("<*secret\_key*") // Secret key paymentPageUrl := gate.GetPaymentPageUrl(*payment) // Complete request with signature ``` ## Processing callbacks {#section_qxm_m24_lhb .section} The Ecommpay payment platform sends payment results to the callback URL you specified when connecting to Ecommpay. Callback is an HTTP POST request that contains response data in JSON format. To extract payment information from the response JSON string, do the following: 1. Create an instance of `gate` and initiate it with the secret key if you did not do it earlier: ```language-php gate := paymentpage.NewGate("<*secret\_key*>") ``` 2. Create an instance of `callback` by using the JSON string from the callback obtained from the Ecommpay payment platform: ```language-php callback, err := gate.HandleCallback(data) ``` If signature is incorrect or extracting payment details from callback results in errors, an `error` instance is returned. 3. Use the following methods for extracting callback information. You can get either full payment information or request specific payment parameters: ```language-php callback.GetPaymentId() // Getting payment ID callback.GetPaymentStatus() // Getting payment status callback.GetPayment() // Getting payment body ``` By using SDK for Go, you can automatically check validity of the callback signature. Below, you can find an example of a callback that includes a signature and payment results. ``` { "project_id": 186, // Project ID "payment": { // Payment details "id": "pid_1555943554067", // Payment ID "type": "purchase", // Payment type "status": "success", // Payment status "date": "2021-08-28T09:11:28+0000", // Payment date and time "method": "card", // Payment method "sum": { // Payment amount and currency "amount": 1000, "currency": "EUR" }, "description": "Test payment" // Payment description }, "account": { // Payment instrument details "number": "431422******0056 ", "token": "9cb38282187b7a5b5b91b5814c6b814162741b29c0c486fbbc500cd451abb8b2", "type": "visa", "card_holder": "ADA LOVELACE", "id": 778804, "expiry_month": "11", "expiry_year": "2024" }, "operation": { // The last operation within payment "id": 17839000001150, // Operation ID "type": "sale", // Operation type "status": "success", // Operation status "date": "2021-08-28T09:11:28+0000", // Operation date and time "created_date": "2021-08-28T09:10:50+0000", "request_id": "2c8af331519833f2c96c4a1aaf60edfcffb...", // Request ID "sum_initial": { // Initial payment amount and currency "amount": 1000, "currency": "EUR" }, "sum_converted": { // Payment amount and currency as per applicable project conversion rules "amount": 1000, "currency": "EUR" }, "provider": { // Payment details in payment system "id": 6, "payment_id": "15354474886323", "date": "2021-02-07T08:34:24+0000", "auth_code": "563253", "endpoint_id": 6 }, "code": "0", // Unified response code "message": "Success", // User-readable response code "eci": "05" // ECI code, result of 3-D Secure check }, "signature": "22YlUIIgoppli/JX8w5F5+c2h12RXi81WLmgDx..." // Signature } ``` ## Related links {#section_skw_c12_phb .section} - [Handling callbacks](en_platform_callbacks.md#) - [Payment processing](en_platform_payment_model.md) **Parent topic:**[Integration using SDK](en_sdk_overview.md) --- # SDK for Java {#en_sdk_java} An article about using data signing SDKs for web services developed in Java. SDK for Java is a software development kit for development of web services which are capable of integrating with the Ecommpay payment solutions to perform purchases by using Payment Page. This section describes how to use SDK for Java to build purchase experience from inside of your web service. SDK for Java is compatible with Java SE Development Kit 8 or higher.You can download SDK for Java from GitHub: [https://github.com/ITECOMMPAY/paymentpage-sdk-java](https://github.com/ITECOMMPAY/paymentpage-sdk-java). ## What can I do with SDK for Java? {#section_mdv_1pf_nhb .section} SDK for Java allows you to do the following: - Calculate signature and generate an URL for opening the Payment Page. - Check callback signatures and extract payment details from callbacks ## What's inside? {#section_myx_rk2_phb .section} SDK for Java contains the following: - **Libraries**for development and automated testing - **Code samples** in Java ## Using SDK for Java {#section_ow5_sdb_mhb .section} To start using SDK for Java you need to complete the following tasks: 1. Make sure you have you have ready your merchant ID and secret key obtained from Ecommpay. 1. If your company has never obtained any ID or secret key from Ecommpay, you need to submit an application for connecting to the Ecommpay payment platformat [https://ecommpay.com/apply-now/](https://ecommpay.com/apply-now/). 2. If your company already has an ID and a secret key to sign messages obtained from Ecommpay, you need to notify the Ecommpay technical support specialists that you want to use SDK for Java and consult the customer support on how to arrange a test run. 2. Integrate the Ecommpay payment solution in your web service: 1. Install the SDK for Java libraries into a directory inside your web service project. 2. Import the libraries you need into your web service application. 3. Test and put your web service in production mode. 1. Request test card numbers and test project ID from Ecommpay, debug and test your web service. 2. Once testing is complete, request your production project ID from Ecommpay and put your web service in production mode. With any questions regarding the use of SDK for Java contact the Ecommpay technical support specialists at [support@ecommpay.com](mailto:support@ecommpay.com). ## Installing and importing libraries {#section_y13_j32_nhb .section} You can install the SDK for Java libraries manually or by using automated procedures supported by the development environment you use. The following steps describe how to manually install the SDK for Java libraries. 1. Download SDK for Java and pack the SDK files into a JAR file. 2. If your project directory does not contain a **libs** directory, create one and move the JAR file into the **libs** directory. 3. Import the file into your web service project by using the procedures pertinent to your development environment. ## Opening payment form {#section_bty_ryn_lhb .section} A URL for opening Payment Page consists of a set of parameters, which are signed to secure the data transmitted to the Ecommpay payment platform. SDK for Java allows you to seamlessly sign parameters and generate URLs. To open the Payment Page payment form by using SDK for Java do the following: 1. Create an instance of the `Payment` class and specify payment details. ```language-java Payment payment = new Payment('186', "pid_1555943554067"); // Project ID and payment ID // Payment ID must be unique within your project scope payment .setParam(Payment.PAYMENT_AMOUNT, 1001) // Amount in minor currency units .setParam(Payment.PAYMENT_CURRENCY, "EUR"); // Currency as per ISO-4217 alpha-3 .setParam(Payment.CUSTOMER_ID, "customer_112") // Customer ID .setParam(Payment.PAYMENT_DESCRIPTION, "Test payment"); // Payment description (optional) ``` All parameters in this example, except for the payment description, are mandatory for any purchase.You may also need to pass other parameters, for example, the customer's email or phone number when the 3‑D Secure authentication is required. Such parameters must be specified as follows. ```language-java .setParam(Payment.CUSTOMER_PHONE, "The customer's phone number. Must have from 4 to 24 digits") .setParam(Payment.CUSTOMER_EMAIL, "The customer's email") ``` In addition, for card purchasesyou are recommended to pass the customer's billing address information: the country code in ISO 3166-1 alpha-2 \([details](en_country_codes.md)\), the postal code, the city, and the street address. Such parameters are specified as follows. ```language-java .setParam(Payment.BILLING_POSTAL, "The postal code of the customer's billing address") .setParam(Payment.BILLING_COUNTRY, "The country of the customer's billing address, in ISO 3166-1 alpha-2t") .setParam(Payment.BILLING_CITY, "The city of the customer's billing address") .setParam(Payment.BILLING_ADDRESS, "The street of the customer's billing address") ``` You can also use any other optional parameters available for Payment Page. For more information about the Payment Page invocation parameters, see [Payment Page API specification](en_PP_Parameters.md). 2. Create a `gate` instance and initiate it with the secret key you obtained from the Ecommpay technical support specialists. The secret key is required to sign parameters. ```language-java Gate gate = new Gate("<*secret\_key*>"); // Secret key you obtained from technical support service ``` 3. Generate the URL for opening the payment form: ```language-java String paymentUrl = gate.getPurchasePaymentPageUrl(payment); ``` The URL must contain payment parameters and signature \(abbreviated\): ```language-java https://paymentpage.ecommpay.com/payment?signature=OEKRlLXQsa2.. ..gWg%3D%3D&payment_id=pid_1555943554067... ``` 4. Use the generated URL for opening the payment form \([details](en_PP_Integration.md)\). Here is an example of generating a URL for opening a payment form in English.The payment method selection page includes detailed payment information including amount, currency, and short payment description. ```language-java Payment payment = new Payment('186', "pid_1555943554067"); // Project ID and payment ID // Payment ID must be unique within your project scope payment .setParam(Payment.PAYMENT_AMOUNT, 1001) // Amount in minor currency units .setParam(Payment.PAYMENT_CURRENCY, "EUR"); // Currency .setParam(Payment.CUSTOMER_ID, "customer_112") // Customer ID .setParam(Payment.PAYMENT_DESCRIPTION, "Test payment"); // Payment description .setParam(Payment.LANGUAGE_CODE, ("en"); // Language code to use in payment form Gate gate = new Gate("<*secret\_key*>"); // Secret key String paymentUrl = gate.getPurchasePaymentPageUrl(payment); // Complete request with signature ``` ## Using the test mode {#section_xv4_3k1_g5b .section} When working with the SDK for Java, you can use the test mode. It allows you to check completeness and correctness of specified parameters and get information about errors if there were any. Before using the test mode, make sure that the server of the web service can send the HTTP requests to `sdk.ecommpay.com`. This allows you to specify various parameters to open the payment form as part of the testing activities \(you will be able to use both test and production parameters\) and to analyse error information. Use the following code: ```language-java Payment payment = new Payment(, ""); payment.payment_amount = 1001; payment.payment_currency = "EUR"; payment.payment_description = "Test payment"; Gate gate = new Gate(''); try { return gate.getPurchasePaymentPageUrl(payment); // Receiving the URL to open the payment form } catch (ValidationException e) { // Validating possible exceptions System.out.println(e); // Error message output } return null; ``` Information about the errors that occurred in testing is provided in error messages as follows: ```language-java One or more parameters is not valid: Customer_id: Must be not null // The id of the customer, required for this request, was not specified Account_token: Invalid account token // Incorrect token value was specified ``` If there are no errors, then the generated URL for opening Payment Page is correct. ## Processing callbacks {#section_qxm_m24_lhb .section} The Ecommpay payment platform sends payment results to the callback URL you specified when connecting to Ecommpay. Callback is an HTTP POST request that contains response data in JSON format. To extract payment information from JSON string do the following: 1. Create an instance of `Gate` with the secret key if you did not do it earlier. ```language-java Gate gate = new Gate("<*secret\_key*>"); ``` 2. Create an instance of `Callback` by using the JSON string from the callback obtained from the Ecommpay payment platform: ```language-java Callback callback = gate.handleCallback(data); ``` 3. Use methods for extracting callback information. You can get either full payment information or request specific payment parameters: ```language-java callback.getPaymentId(); // Getting payment ID callback.getPaymentStatus(); // Getting payment status callback.getPayment(); // Getting payment body ``` By using SDK for Java, you can automatically check validity of callback signature. Below, you will find an example of callback that includes signature and payment results. ``` { "project_id": 186, // Project ID "payment": { // Payment details "id": "pid_1555943554067", // Payment ID "type": "purchase", // Payment type "status": "success", // Payment status "date": "2021-08-28T09:11:28+0000", // Payment date and time "method": "card", // Payment method "sum": { // Payment amount and currency "amount": 1001, "currency": "EUR" }, "description": "Test payment" // Payment description }, "account": { // Payment instrument details "number": "431422******0056 ", "token": "9cb38282187b7a5b5b91b5814c6b814162741b29c0c486fbbc500cd451abb8b2", "type": "visa", "card_holder": "ADA LOVELACE", "id": 778804, "expiry_month": "11", "expiry_year": "2024" }, "operation": { // The last operation within payment "id": 17839000001150, // Operation ID "type": "sale", // Operation type "status": "success", // Operation status "date": "2021-08-28T09:11:28+0000", // Operation date and time "created_date": "2021-08-28T09:10:50+0000", "request_id": "2c8af331519833f2c96c4a1aaf60edfcffb...", // Request ID "sum_initial": { // Initial payment amount and currency "amount": 1001, "currency": "EUR" }, "sum_converted": { // Payment amount and currency as per applicable project conversion rules "amount": 1001, "currency": "EUR" }, "provider": { // Payment details in payment system "id": 6, "payment_id": "15354474886323", "date": "2021-02-07T08:34:24+0000", "auth_code": "563253", "endpoint_id": 6 }, "code": "0", // Unified response code "message": "Success", // User-readable response code "eci": "05" // ECI code, result of 3-D Secure check }, "signature": "22YlUIIgoppli/JX8w5F5+c2h12RXi81WLmgDx..." // Signature } ``` ## Related links {#section_skw_c12_phb .section} - [Handling callbacks](en_platform_callbacks.md#) - [Payment processing](en_platform_payment_model.md) **Parent topic:**[Integration using SDK](en_sdk_overview.md) --- # SDK for JavaScript {#en_sdk_javascript} An article about using data signing SDKs for web services developed in JavaScript. SDK for JavaScript is a software development kit for development of web services which are capable of integrating with the Ecommpay payment solutions to perform purchases by using Payment Page. This section describes how to use SDK for JavaScript to build purchase experience from inside of your web service. SDK for JavaScript is compatible with the Node.js 4.x runtime environment for executing JavaScript code.You can download SDK for JavaScript from GitHub: [https://github.com/ITECOMMPAY/paymentpage-sdk-js](https://github.com/ITECOMMPAY/paymentpage-sdk-js). ## What can I do with SDK for JavaScript? {#section_mdv_1pf_nhb .section} SDK for JavaScript allows you to do the following: - Calculate signature and generate an URL for opening the Payment Page. - Check callback signature and extract payment details from callbacks ## What's inside? {#section_rlb_55f_nhb .section} SDK for JavaScript contains the following: - **src**—a library for development - **\_tests\_**—a library for automatic testing ## Using SDK for JavaScript {#section_ow5_sdb_mhb .section} To start using SDK for JavaScript you need to complete the following tasks: 1. Make sure you have you have ready your merchant ID and secret key obtained from Ecommpay. 1. If your company has never obtained any ID or secret key from Ecommpay, you need to submit an application for connecting to the Ecommpay payment platformat [https://ecommpay.com/apply-now/](https://ecommpay.com/apply-now/). 2. If your company already has an ID and a secret key to sign messages obtained from Ecommpay, you need to notify the Ecommpay technical support specialists that you want to use SDK for JavaScript and consult the customer support on how to arrange a test run. 2. Integrate the Ecommpay payment solution in your web service: 1. Install the SDK for JavaScript libraries into a directory inside your web service project. 2. Import the libraries you need into your web service application. 3. Test and put your web service in production mode. - Use test merchant ID and test values for payment parameters from the **\_tests\_** library. - Once testing is complete, request your production merchant ID from Ecommpay and put your web service in production mode. With any questions regarding the use of SDK for JavaScript contact the Ecommpay technical support specialists at [support@ecommpay.com](mailto:support@ecommpay.com). ## Installing and importing libraries {#section_y13_j32_nhb .section} You can install the SDK for JavaScript libraries manually or automatically with Yarn or npm, package-management systems used to install and manage software packages written in JavaScript. The following steps describe how to install the SDK for JavaScript libraries by using Yarn or npm: 1. If you have not yet installed a package-management system, you need to download, install and check settings. For more information, see: - Yarn: [https://yarnpkg.com/en/docs/getting-started](https://yarnpkg.com/en/docs/getting-started) - npm: [https://www.npmjs.com/package/ecommpay](https://www.npmjs.com/package/ecommpay) 2. Navigate into the web service source code directory in command line and run one of the following commands: ```language-javascript npm install ecommpay // for npm yarn add ecommpay // for Yarn ``` A package-management system automatically downloads the SDK for JavaScript libraries in the source code directory to enable you to use all the modules provided by the libraries. 3. Import the modules into your web service project: ```language-javascript const { Payment } = require('ecommpay'); const { Callback } = require('ecommpay'); ``` ## Opening payment form {#section_bty_ryn_lhb .section} A URL for opening Payment Page consists of a set of parameters, which are signed to secure the data transmitted to the Ecommpay payment platform. SDK for JavaScript allows you to seamlessly sign parameters and generate URLs. To open the Payment Page payment form by using SDK for JavaScript do the following: 1. Create an instance of the `Payment` class and specify payment details and the secret key you obtained from the Ecommpay technical support specialists. The secret key is required to sign parameters. ```language-javascript const e = new Payment('186', '<*secret\_key*>'); // Project ID and Secret key e.paymentId = 'TEST_1555943554067'; // Payment ID must be unique within your project scope e.paymentAmount = 1000; // Amount in minor currency units e.paymentCurrency = 'EUR'; // Currency in ISO-4217 alpha-3 format e.customerId = 'customer_112'; // Customer ID e.paymentDescription = 'Payment description'; // Payment description (optional) ``` All parameters in this example, except for the payment description, are mandatory for any purchase.You may also need to pass other parameters, for example, the customer's email or phone number when the 3‑D Secure authentication is required. Such parameters must be specified as follows. ```language-javascript e.paymentCustomerPhone = 'The customer phone number. Must have from 4 to 24 digits'; e.paymentCustomerEmail = 'The customer email'; ``` In addition, for card purchasesyou are recommended to pass the customer's billing address information: the country code in ISO 3166-1 alpha-2 \([details](en_country_codes.md)\), the postal code, the city, and the street address. Such parameters are specified as follows. ```language-javascript e.paymentBillingPostal = 'The postal code of the customer billing address'; e.paymentBillingCountry = 'The country of the customer billing address, in ISO 3166-1 alpha-2'; e.paymentBillingCity = 'The city of the customer billing address'; e.paymentBillingAddress = 'The street of the customer billing address'; ``` You can also use any other optional parameters available for Payment Page. For more information about the Payment Page invocation parameters, see [Payment Page API specification](en_PP_Parameters.md). 2. Generate the URL for opening the payment form: ```language-javascript const url = e.getUrl(); ``` The URL must contain payment parameters and signature \(abbreviated\): ```language-javascript https://paymentpage.ecommpay.com/payment?signature=OEKRlLXQsa2.. ..gWg%3D%3D&payment_id=pid_1555943554067... ``` 3. Use the generated URL for opening the payment form \([details](en_PP_Integration.md)\). Here is an example of generating a URL for opening a payment form in English.The payment method selection page includes detailed payment information including amount, currency, and short payment description. ```language-javascript const e = new Payment('186', '<*secret\_key*>'); // Project ID and Secret key e.paymentId = 'TEST_1555943554067'; // Payment ID must be unique within your project scope e.paymentAmount = 1000; // Amount in minor currency units e.paymentCurrency = 'EUR'; // Currency in ISO-4217 alpha-3 format e.customerId = 'customer_112'; // Customer ID e.paymentDescription = 'Payment description'; // Payment description (optional) e.language_code: 'EN'; // Language code to use in payment form const url = e.getUrl(); // Complete request with signature ``` ## Processing callbacks {#section_qxm_m24_lhb .section} The Ecommpay payment platform sends payment results to the callback URL you specified when connecting to Ecommpay. Callback is an HTTP POST request that contains response data in JSON format in the `req.body` object. To extract payment information from JSON string, do the following: 1. Create an instance of `Callback` by using the secret key and the JSON string from the callback obtained from the Ecommpay payment platform: ```language-javascript const callback = new Callback(<*secret\_key*>, req.body); ``` 2. The following example contains the methods for extracting callback information in the source code that uses the Express framework: ```language-javascript app.post('/payment/callback', function(req, res) { const callback = new Callback(<*secret\_key*>, req.body); if (callback.isPaymentSuccess()) { const paymentCont = callback.payment(); // Getting information about the payment const paymentId = callback.getPaymentId(); // Getting payment ID // Add your code for proccessing successful payment } }); ``` By using SDK for JavaScript, you can automatically check validity of callback signature. Below, you will find an example of callback that includes signature and payment results. ``` { "project_id": 186, // Project ID "payment": { // Payment details "id": "pid_1555943554067", // Payment ID "type": "purchase", // Payment type "status": "success", // Payment status "date": "2021-08-28T09:11:28+0000", // Payment date and time "method": "card", // Payment method "sum": { // Payment amount and currency "amount": 1000, "currency": "EUR" }, "description": "Test payment" // Payment description }, "account": { // Payment instrument details "number": "431422******0056 ", "token": "9cb38282187b7a5b5b91b5814c6b814162741b29c0c486fbbc500cd451abb8b2", "type": "visa", "card_holder": "ADA LOVELACE", "id": 778804, "expiry_month": "11", "expiry_year": "2024" }, "operation": { // The last operation within payment "id": 17839000001150, // Operation ID "type": "sale", // Operation type "status": "success", // Operation status "date": "2021-08-28T09:11:28+0000", // Operation date and time "created_date": "2021-08-28T09:10:50+0000", "request_id": "2c8af331519833f2c96c4a1aaf60edfcffb...", // Request ID "sum_initial": { // Initial payment amount and currency "amount": 1000, "currency": "EUR" }, "sum_converted": { // Payment amount and currency as per applicable project conversion rules "amount": 1000, "currency": "EUR" }, "provider": { // Payment details in payment system "id": 6, "payment_id": "15354474886323", "date": "2021-02-07T08:34:24+0000", "auth_code": "563253", "endpoint_id": 6 }, "code": "0", // Unified response code "message": "Success", // User-readable response code "eci": "05" // ECI code, result of 3-D Secure check }, "signature": "22YlUIIgoppli/JX8w5F5+c2h12RXi81WLmgDx..." // Signature } ``` ## Related links {#section_skw_c12_phb .section} - [Handling callbacks](en_platform_callbacks.md#) - [Payment processing](en_platform_payment_model.md) **Parent topic:**[Integration using SDK](en_sdk_overview.md) --- # SDK for PHP {#en_sdk_php} An article about using data signing SDKs for web services developed in PHP. SDK for PHP is a software development kit for development of web services which are capable of integrating with the Ecommpay payment solutions to perform purchase by using Payment Page. This section describes how to use SDK for PHP to build purchase experience from inside of your web service. SDK for PHP is compatible with PHP version 7.0 or higher.You can download SDK for PHP from GitHubor Packagist: - GitHub: [https://github.com/ITECOMMPAY/paymentpage-sdk-php](https://github.com/ITECOMMPAY/paymentpage-sdk-php) - Packagist: [https://packagist.org/packages/ecommpay/paymentpage-sdk](https://packagist.org/packages/ecommpay/paymentpage-sdk) ## What can I do with SDK for PHP? {#section_mdv_1pf_nhb .section} SDK for PHP allows you to do the following: - Calculate signature and generate an URL for opening the Payment Page. - Check callback signature and extract payment details from callbacks. ## What's inside? {#section_rlb_55f_nhb .section} SDK for PHP contains the following: - **src**—a library for development - **tests**—a library for automatic testing - **composer.json**—a script for importing libraries - **The service files** ## Using SDK for PHP {#section_ow5_sdb_mhb .section} To start using SDK for PHP you need to complete the following tasks: 1. Make sure you have ready your merchant ID and secret key obtained from Ecommpay: 1. If your company has never obtained any ID or secret key from Ecommpay, you need to submit an application for connecting to the Ecommpay payment platformat [https://ecommpay.com/apply-now/](https://ecommpay.com/apply-now/). 2. If your company already has an ID and a secret key to sign messages obtained from Ecommpay, you need to notify Ecommpay customer support that you want to use SDK for PHP and consult the customer support on how to arrange a test run. 2. Integrate the Ecommpay payment solution in your web service: 1. Install the SDK for PHP libraries into a directory inside your web service project. 2. Import the libraries you need into your web service application. 3. Test and put your web service in production mode. - Use test merchant ID and test values for payment parameters from the **tests** library. - Once testing is complete, request your production merchant ID from Ecommpay and put your web service in production mode. With any questions regarding the use of SDK for PHP contact the Ecommpay technical support specialists at [support@ecommpay.com](mailto:support@ecommpay.com). ## Installing and importing libraries {#section_y13_j32_nhb .section} You can install the SDK for PHP libraries manuallyor automatically with Composer, a dependency manager for PHP programming language. Composer can download and install the libraries required for a project, as well as generate a script for importing the libraries. The following steps describe how to install the SDK for PHP libraries by using Composer: 1. If you have not yet installed Composer, you need to download, install and check settings. For more information, see [https://getcomposer.org/](https://getcomposer.org/). 2. Navigate into the web service source code directory in command line interface and run the following command: ```language-php composer require ecommpay/paymentpage-sdk ``` Composer automatically downloads the SDK for PHP in the **vendor** sub-directory and creates the **autoload.php** script required to enable you to use all the classes provided by the libraries. 3. Include the **autoload.php** script into your web service project: ```php require __DIR__.'../../vendor.autoload.php'; ``` ## Opening payment form {#section_bty_ryn_lhb .section} A URL for opening Payment Page consists of a set of parameters, which are signed to secure the data transmitted to the Ecommpay payment platform. SDK for PHP allows you to seamlessly sign parameters and generate URLs. To open the Payment Page payment form by using SDK for PHP do the following: 1. Create an instance of the `Payment` class and specify payment details. ```language-php $payment = new ecommpay\Payment('186', 'TEST_1555943554067'); // Project ID and payment ID and payment ID must be unique within your project scope $payment->setPaymentAmount(1000)->setPaymentCurrency('EUR'); // Amount in minor currency units and currency in the ISO-4217 alpha-3 format $payment->setCustomerId('customer007'); // Customer ID $payment->setPaymentDescription('Test payment'); // Payment description (optional) ``` All parameters in this example, except for the payment description, are mandatory for any purchase.You may also need to pass other parameters, for example, the customer's email or phone number when the 3‑D Secure authentication is required. Such parameters must be specified as follows. ```language-php $payment->setCustomerPhone('The customer phone number. Must have from 4 to 24 digits'); $payment->setCustomerEmail('The customer email'); ``` In addition, for card purchasesyou are recommended to pass the customer's billing address information: the country code in ISO 3166-1 alpha-2 \([details](en_country_codes.md)\), the postal code, the city, and the street address. Such parameters are specified as follows. ```language-php $payment->setBillingPostal('The postal code of the customer billing address'); $payment->setBillingCountry('The country of the customer billing address, in ISO 3166-1 alpha-2'); $payment->setBillingCity('The city of the customer billing address'); $payment->setBillingAddress('The street of the customer billing address'); ``` You can also use any other optional parameters available for Payment Page. For more information about the Payment Page invocation parameters, see [Payment Page API specification](en_PP_Parameters.md). 2. Create a `gate` instance and initiate it with the secret key you obtained from the Ecommpay technical support specialists. The secret key is required to sign parameters. ```language-php $gate = new ecommpay\Gate('<*secret\_key*>'); // Secret key you obtained from the technical support service ``` 3. Generate the URL for opening the payment form: ```language-php $url = $gate->getPurchasePaymentPageUrl($payment); ``` The URL must contain payment parameters and signature \(abbreviated\): ```language-php https://paymentpage.ecommpay.com/payment?signature=OEKRlLXQsa2.. ..gWg%3D%3D&payment_id=pid_1555943554067... ``` 4. Use the generated URL for opening the payment form \([details](en_PP_Integration.md)\). Here is an example of generating a URL for opening a payment form in English.The payment method selection page includes detailed payment information including amount, currency, and short payment description while the data input page includes a countdown timer. ```language-php $gate = new ecommpay\Gate('<*secret\_key*>'); // Secret key $payment = new ecommpay\Payment('186', 'TEST_1555943554067'); // Project ID and payment ID and payment ID must be unique within your project scope $payment->setPaymentAmount(1000)->setPaymentCurrency('EUR'); // Amount in minor currency units and currency in ISO-4217 alpha-3 format $payment->setCustomerId('customer007'); // Customer ID $payment->setPaymentDescription('Test payment'); // Payment description $payment->setBestBefore(new \DateTime('2050-01-01 00:00:00 +0000')); // Date and time for timer countdown $payment->setLanguageCode('en'); // Language code to use in payment form $url = $gate->getPurchasePaymentPageUrl($payment); // Complete request with signature ``` ## Using the test mode {#section_l2r_2l1_g5b .section} When working with the SDK for PHP, you can use the test mode. It allows you to check completeness and correctness of specified parameters and get information about errors if there were any. Before using the test mode, make sure that the server of the web service can send the HTTP requests to `sdk.ecommpay.com` and that your PHP interpreter meets at least one of the following requirements: - It supports the `curl` library \([more](https://www.php.net/manual/en/book.curl.php)\). - It supports the `sockets` library with the HTTP access to the URL \([more](https://www.php.net/manual/en/book.sockets.php)\). - The directive `allow_fopen_url` is set to `true` and the HTTP access to the URL is supported \([more](https://www.php.net/manual/en/function.fopen.php)\). This will allow you to specify various parameters to open the payment form as part of the testing activities \(you will be able to use both test and production parameters\) and to analyse error information. Use the following code: ```language-php $payment = new Payment(, ''); $payment->setPaymentAmount(1000) ->setPaymentCurrency('EUR') ->setPaymentDescription('Test payment') $gate = new Gate(''); try { return $gate->getPaymentPageUrl($payment); // Receiving the URL to open the payment form } catch (ValidationException $e) { // Validating possible exceptions error_log($e->getFormattedMessage()); // Logging the error message } return null; ``` Information about the errors that occurred in testing is provided in error messages as follows: ```language-php One or more parameters is not valid: Customer_id: Must be not null // The id of the customer, required for this request, was not specified Account_token: Invalid account token // Incorrect token value was specified ``` If there are no errors, then the generated URL for opening Payment Page is correct. ## Processing callbacks {#section_qxm_m24_lhb .section} The Ecommpay payment platform sends payment results to the callback URL you specified when connecting to Ecommpay. Callback is an HTTP POST request that contains response data in JSON format. To extract payment information from a JSON string do the following: 1. Create an instance of `Gate` with the secret key, if you did not it earlier. ```language-php $gate = new ecommpay\Gate('<*secret\_key*>'); ``` 2. Create an instance of `Callback` by using the JSON string from the callback obtained from the Ecommpay payment platform: ```language-php $callback = $gate->handleCallback($data); ``` 3. Use the following methods to obtain the callback information. You can get either full payment information or request specific payment parameters: ```language-php Callback::getPaymentId(); // Getting payment ID Callback::getPaymentStatus(); // Getting payment status Callback::getPayment(); // Getting payment body ``` By using SDK for PHP, you can automatically check validity of callback signature. Below, you will find an example of callback that includes signature and payment results. ``` { "project_id": 186, // Project ID "payment": { // Payment details "id": "pid_1555943554067", // Payment ID "type": "purchase", // Payment type "status": "success", // Payment status "date": "2021-08-28T09:11:28+0000", // Payment date and time "method": "card", // Payment method "sum": { // Payment amount and currency "amount": 1000, "currency": "EUR" }, "description": "Test payment" // Payment description }, "account": { // Payment instrument details "number": "431422******0056 ", "token": "9cb38282187b7a5b5b91b5814c6b814162741b29c0c486fbbc500cd451abb8b2", "type": "visa", "card_holder": "ADA LOVELACE", "id": 778804, "expiry_month": "11", "expiry_year": "2024" }, "operation": { // The last operation within payment "id": 17839000001150, // Operation ID "type": "sale", // Operation type "status": "success", // Operation status "date": "2021-08-28T09:11:28+0000", // Operation date and time "created_date": "2021-08-28T09:10:50+0000", "request_id": "2c8af331519833f2c96c4a1aaf60edfcffb...", // Request ID "sum_initial": { // Initial payment amount and currency "amount": 1000, "currency": "EUR" }, "sum_converted": { // Payment amount and currency as per applicable project conversion rules "amount": 1000, "currency": "EUR" }, "provider": { // Payment details in payment system "id": 6, "payment_id": "15354474886323", "date": "2021-02-07T08:34:24+0000", "auth_code": "563253", "endpoint_id": 6 }, "code": "0", // Unified response code "message": "Success", // User-readable response code "eci": "05" // ECI code, result of 3-D Secure check }, "signature": "22YlUIIgoppli/JX8w5F5+c2h12RXi81WLmgDx..." // Signature } ``` ## Related links {#section_skw_c12_phb .section} - [Handling callbacks](en_platform_callbacks.md#) - [Payment processing](en_platform_payment_model.md) **Parent topic:**[Integration using SDK](en_sdk_overview.md) --- # SDK for Python {#en_sdk_python} An article about using data signing SDKs for web services developed in Python. SDK for Python is a software development kit for development of web services which are capable of integrating with the Ecommpay payment solutions to perform purchase by using Payment Page. This section describes how to use SDK for Python to build purchase experience from inside of your web service. SDK for Python is compatible with Python version 3.5 or higher.You can download SDK for Python from GitHubor PyPI: - GitHub: [https://github.com/ITECOMMPAY/paymentpage-sdk-python](https://github.com/ITECOMMPAY/paymentpage-sdk-python) - PyPI: [https://pypi.org/project/ecommpay-sdk/](https://pypi.org/project/ecommpay-sdk/) ## What can I do with SDK for Python? {#section_mdv_1pf_nhb .section} SDK for Python allows you to do the following: - Calculate signature and generate an URL for opening the Payment Page. - Check callback signature and extract payment details from callbacks. ## What's inside? {#section_rlb_55f_nhb .section} SDK for Python contains the libraries for development and automated testing, as well as the service files. ## Using SDK for Python {#section_ow5_sdb_mhb .section} To start using SDK for Python you need to complete the following tasks: 1. Make sure you have you have ready your merchant ID and secret key obtained from Ecommpay: 1. If your company has never obtained any ID or secret key from Ecommpay, you need to submit an application for connecting to the Ecommpay payment platformat [https://ecommpay.com/apply-now/](https://ecommpay.com/apply-now/). 2. If your company already has an ID and a secret key to sign messages obtained from Ecommpay, you need to notify the Ecommpay technical support that you want to use SDK for Python and consult the customer support on how to arrange a test run. 2. Integrate the Ecommpay payment solution in your web service: 1. Install the SDK for Python libraries. 2. Import the libraries you need into your web service application. 3. Test and put your web service in production mode. - Use test merchant ID and test values for payment parameters from the **tests** library. - Once testing is complete, request your production merchant ID from Ecommpay and put your web service in production mode. With any questions regarding the use of SDK for Python, contact Ecommpay the technical support specialists at [support@ecommpay.com](mailto:support@ecommpay.com). ## Installing and importing libraries {#section_y13_j32_nhb .section} You can install the SDK for Python libraries manually or automatically with pip, a package-management system used to install and manage software packages written in [Python](https://en.wikipedia.org/wiki/Python_(programming_language)). The following steps describe how to install the SDK for Python libraries by using pip: 1. If you have not yet installed pip, you need to download, install and check settings. For more information, see [https://pip.pypa.io/en/stable/](https://pip.pypa.io/en/stable/). 2. Navigate into the web service directory in command line interface and run the following command: ```language-python pip install ecommpay-sdk ``` Pip automatically downloads the SDK for Python libraries in the **Scripts** directory to enable you to use all the classes provided by the libraries. 3. Import the classes into your web service project: ```language-python from payment_page_sdk.gate import Gate from payment_page_sdk.payment import Payment ``` ## Opening payment form {#section_bty_ryn_lhb .section} A URL for opening Payment Page consists of a set of parameters, which are signed to secure the data transmitted to the Ecommpay payment platform. SDK for Python allows you to seamlessly sign parameters and generate URLs. To open the Payment Page payment form by using SDK for Python do the following: 1. Create an instance of the Payment class and specify payment details. ```language-python payment = Payment('186', 'TEST_1555943554067') // Project ID and payment ID and payment ID must be unique within your project scope payment.payment_amount = 1001 // Amount in minor currency units payment.payment_currency = 'EUR' // Currency in ISO-4217 alpha-3 format payment.customer_id = 'customer_112' // Customer ID payment.payment_description = 'Test payment' // Payment description (optional) ``` All parameters in this example, except for the payment description, are mandatory for any purchase.You may also need to pass other parameters, for example, the customer's email or phone number when the 3‑D Secure authentication is required. Such parameters must be specified as follows. ```language-python payment.customer_phone = 'The customer phone number. Must have from 4 to 24 digits' payment.customer_email = 'The customer email' ``` In addition, for card purchasesyou are recommended to pass the customer's billing address information: the country code in ISO 3166-1 alpha-2 \([details](en_country_codes.md)\), the postal code, the city, and the street address. Such parameters are specified as follows. ```language-python payment.billing_postal = 'The postal code of the customer billing address' payment.billing_country = 'The country of the customer billing address, in ISO 3166-1 alpha-2' payment.billing_city = 'The city of the customer billing address' payment.billing_address = 'The street of the customer billing address' ``` You can also use any other optional parameters available for Payment Page. For more information about the Payment Page invocation parameters, see [Payment Page API specification](en_PP_Parameters.md). 2. Create a `gate` instance and initiate it with the secret key you obtained from Ecommpay. The secret key is required to sign parameters. ```language-python gate = Gate('<*secret\_key*>') // Secret key you obtained from technical support service ``` 3. Generate the URL for opening the payment form: ```language-python payment_url = gate.get_purchase_payment_page_url(payment) ``` The URL must contain payment parameters and signature \(abbreviated\): ```language-python https://paymentpage.ecommpay.com/payment?signature=OEKRlLXQsa2.. ..gWg%3D%3D&payment_id=pid_1555943554067... ``` 4. Use the generated URL for opening the payment form \([details](en_PP_Integration.md)\). Here is an example of generating a URL for opening a payment form in English.The payment method selection page includes detailed payment information including amount, currency, and short payment description. ```language-python payment = Payment('186', 'TEST_1555943554067') // Project ID and payment ID and payment ID must be unique within your project scope payment.payment_amount = 1001 payment.payment_currency = 'EUR' // Amount in minor currency units and currency in ISO-4217 alpha-3 format payment.customer_id = 'customer_112' // Customer ID payment.payment_description = 'Test payment' // Payment description payment.language_code = 'en' // Language code to use in payment form gate = Gate('<*secret\_key*>') // Secret key payment_url = gate.get_purchase_payment_page_url(payment) // Complete request with signature ``` ## Using the test mode {#section_s5f_rq1_g5b .section} When working with the SDK for Python, you can use the test mode. It allows you to check completeness and correctness of specified parameters and get information about errors if there were any. Before using the test mode, make sure that the server of the web service can send the HTTP requests to `sdk.ecommpay.com`. This allows you to specify various parameters to open the payment form as part of the testing activities \(you will be able to use both test and production parameters\) and to analyse error information. Use the following code: ```language-python payment = Payment(, "") payment.payment_amount = 1001 payment.payment_currency = 'EUR' payment.payment_description = 'Test payment' gate = Gate("") try: # Attempting to execute the code return gate.get_purchase_payment_page_url(payment) # Receiving the URL to opent the payment form except ValidationException as e: # Validating possible exceptions print(e) # Displaying error messages in the console return null ``` Information about the errors that occurred in testing is provided in error messages as follows: ```language-php One or more parameters is not valid: Customer_id: Must be not null // The id of the customer, required for this request, was not specified Account_token: Invalid account token // Incorrect token value was specified ``` If there are no errors, then the generated URL for opening Payment Page is correct. ## Processing callbacks {#section_qxm_m24_lhb .section} The Ecommpay payment platform sends payment results to the callback URL you specified when connecting to Ecommpay. Callback is an HTTP POST request that contains response data in JSON format. To extract payment information from the JSON string do the following: 1. Create an instance of `Gate` with the secret key, if you did not it earlier. ```language-python gate = Gate('<*secret\_key*>') ``` 2. Create an instance of `Callback` by using the JSON string from the callback obtained from the Ecommpay payment platform: ```language-python callback = gate.handle_callback(data) ``` 3. Use the following methods for extracting callback information. You can get either full payment information or request specific payment parameters: ```language-python callback.get_payment_id() // Getting payment ID callback.get_payment_status() // Getting payment status callback.get_payment() // Getting payment body ``` By using SDK for Python, you can automatically check validity of callback signature. Below, you will find an example of callback that includes signature and payment results. ```language-json { "project_id": 186, // Project ID "payment": { // Payment details "id": "pid_1555943554067", // Payment ID "type": "purchase", // Payment type "status": "success", // Payment status "date": "2021-08-28T09:11:28+0000", // Payment date and time "method": "card", // Payment method "sum": { // Payment amount and currency "amount": 1001, "currency": "EUR" }, "description": "Test payment" // Payment description }, "account": { // Payment instrument details "number": "431422******0056 ", "token": "9cb38282187b7a5b5b91b5814c6b814162741b29c0c486fbbc500cd451abb8b2", "type": "visa", "card_holder": "ADA LOVELACE", "id": 778804, "expiry_month": "11", "expiry_year": "2024" }, "operation": { // The last operation within payment "id": 17839000001150, // Operation ID "type": "sale", // Operation type "status": "success", // Operation status "date": "2021-08-28T09:11:28+0000", // Operation date and time "created_date": "2021-08-28T09:10:50+0000", "request_id": "2c8af331519833f2c96c4a1aaf60edfcffb...", // Request ID "sum_initial": { // Initial payment amount and currency "amount": 1001, "currency": "EUR" }, "sum_converted": { // Payment amount and currency as per applicable project conversion rules "amount": 1001, "currency": "EUR" }, "provider": { // Payment details in payment system "id": 6, "payment_id": "15354474886323", "date": "2021-02-07T08:34:24+0000", "auth_code": "563253", "endpoint_id": 6 }, "code": "0", // Unified response code "message": "Success", // User-readable response code "eci": "05" // ECI code, result of 3-D Secure check }, "signature": "22YlUIIgoppli/JX8w5F5+c2h12RXi81WLmgDx..." // Signature } ``` ## Related links {#section_skw_c12_phb .section} - [Handling callbacks](en_platform_callbacks.md#) - [Payment processing](en_platform_payment_model.md) **Parent topic:**[Integration using SDK](en_sdk_overview.md) --- # Integration using plug-ins {#en_CMS} Articles about using plug-ins for embedding Payment Page into websites powered by various CMS and specialised platforms. Modern content management systems\(CMSs\)and specialised platforms allow you to launch, maintain, and further develop the web services for your business quickly and efficiently. For the easiest possible integration of such web services with the payment platform, Ecommpay provides merchants with the specialised integration modules—plug-ins.With each plug-in, you can promptly connect your web service created in a popular system to the Ecommpay platform and process payments using the Payment Page payment form, with all necessary interactions between the web service and the payment platform set up. The Ecommpay plug-ins allow integrating the platform and web services that operate with the use of the following systems: - [BigCommerce](en_cms_bigcommerce.md#) - [commercetools](en_cms_commercetools.md#)with the use of the Composable Commerce solution - [Magento](en_CMS__magento.md#) version 2.2 or later - [PrestaShop](en_cms_prestashop.md#) version 8.1.5 or later - [WordPress](en_CMS__wordpress.md#) version6.2or later If you have any questions regarding the usage of the Ecommpay plug-ins or suggestions as to how their functionality can be expanded and enhanced, contact your Ecommpay account manager. With questions about integrating, testing, and using these plug-ins, contact the technical support specialists. - **[Using Ecommpay Payments plug-in for the BigCommerce platform](en_cms_bigcommerce.md#)** An article about using a plug-in for embedding Payment Page into websites powered by the BigCommerce platform. - **[Using plug-in from Ecommpay for commercetools](en_cms_commercetools.md#)** An article about using a plug-in for embedding Payment Page into websites powered by the commercetools platform. - **[Using plug-in from Ecommpay for Magento CMS](en_CMS__magento.md#)** An article about using a plug-in for embedding Payment Page into websites powered by the Magento CMS platform. - **[Using Ecommpay payments for PrestaShop CMS](en_cms_prestashop.md#)** An article about using a plug-in for embedding Payment Page into websites powered by the PrestaShop CMS platform. - **[Using Ecommpay Payments plug-in for WordPress CMS](en_CMS__wordpress.md#)** An article about using a plug-in for embedding Payment Page into websites powered by the WordPress CMS platform with the installed WooCommerce plug-in. **Parent topic:**[Payment Page](en_PP_about.md) --- # Using Payment Page in embedded mode for card payments {#en_pp_microframe_solution} An article about using Payment Page embedded mode edition to accept standard card payments. ## Overview {#section_bym_5hy_k3c .section} In certain processing scenarios merchants may need to use a minimalist payment form embedded into the user interface of their web servicewhich allows their customers to have a faster and optimised checkout experience as compared to standard solutions, at least in case of the most frequently used payments. When working with the Ecommpay payment platform, you can use a specialised *embedded mode edition* of Payment Pagewith the least number of input fields and without the payment confirmation button \(the expectation being that the button or any other element is to be developed on the merchant web service side\). ![](images/ecommpay/en_pp_microframe_solution_1.svg "Interface of the payment form in embedded mode. Essential fields") The *embedded mode edition* is intended for processing standard card payments with support of the most relevant procedures and capabilities. To work with augmented processing scenarios as well as to accept alternative payments, you can use other editions of Payment Page. You can implement and use several editions of the payment form at the same time and customise them to fit the needs of your web service.For example, you can use Payment Page in embedded mode to process card payments and implement a specialised edition with embedded buttons for Apple Pay and Google Pay payments \([details](en_pp_embedded_payment_buttons.md#)\), while relying on the standard edition of Payment Page for accepting payments with other payment methods. ![](images/ecommpay/microframe_1.svg "Combining several editions of the payment form to accept different payment methods") ## Capabilities {#section_oq2_2rf_l3c .section} When working with Payment Page in embedded mode, you can: - Customise the appearance of the payment form using the **Payment Page Designer**in Dashboard \([details](en_PP__design_customisation.md#)\). - Customise the fields to be displayed on the payment form. You can remove the field to enter the cardholder's name \(if this option is enabled for the project\)and add fields to collect additional customer data\([details](en_PP_Gathering_customer_data.md)\). - Enable your customers to save card details, subsequently use them to pay, or remove them\(this option is available by default, but it can be disabled upon agreement with the Ecommpay account manager\). - Accept one-timeone-step and two-step card purchases and perform card verification, with the option to register COF purchases available in both cases and the capability to execute relevant auxiliary proceduressuch as 3‑D Secure authentication, AVS checks, and submitting additional payment information. ## Processing scenario {#section_vhx_ctf_l3c .section} The basic steps of the customer payment scenario with the use of Payment Page in embedded mode are the following: ![](images/ecommpay/en_pp_microframe_solution_scenario_1.svg "Opening the payment form") ![](images/ecommpay/en_pp_microframe_solution_scenario_2.svg "Entering card details") ![](images/ecommpay/en_pp_microframe_solution_scenario_3.svg "Web service preloader") ![](images/ecommpay/en_pp_microframe_solution_scenario_4.svg "3‑D Secure authentication") ![](images/ecommpay/en_pp_microframe_solution_scenario_5.svg "Redirecting to the web service") 1. The customer initiates the purchase in the web service following which the customer can provide the details of the card. At this step, the payment form can contain the card selection tabs \(if this customer saved any cards before\) and fields to enter the card details to be used for payment as well as additional fields and the checkbox to consent to saving the card details \(if this option is set up for the project\). 2. The customer provides necessary data and confirms the payment. If the data is missing or entered incorrectly, the customer is shown notifications about it in the payment form. 3. The customer is shown the preloader. This can be done either in the interface of the payment form or in the interface of the web service, depending on the web service configuration. Note that the payment form remains open throughout. 4. If it is necessary for payment processing, the customer is shown the forms for performing additional actions which the customer then executes. These additional forms include the modal window with the fields to enter additional data shown in the web service \(over the payment form\) and the page to perform the 3‑D Secure authentication, shown in the iframe element of the payment form instead of the payment form. 5. The customer is shown the payment result information. This involves the use of the payment form, and if it is configured in the web service, then the web service as well. ## Workflow {#section_vqs_wyf_l3c .section} Processing a purchase made via Payment Page in embedded mode requires the interaction between the web service and the payment form with the use of the specialised libraries from Ecommpay. In a standard case, when the web service displays its own preloader page \(over the interface of the payment form\), the interaction is carried out as follows. **Note:** There is no need to redirect the customer to a separate preloader page or repeatedly check the payment status from your backend — Payment Page checks the status directly and sends the corresponding callback once a final payment result is received. ![](images/ecommpay/en_pp_microframe_solution_uml.svg) 1. A customer initiates a purchase in the web service. 2. The web service invokes Payment Page with the use of the `EPayWidget.runEmbedded` method. 3. The request for opening Payment Page is sent to the payment platform. 4. The payment platform receives the request and validates the required parameters and signature. 5. Payment Page is generated based on the project and request parameters. 6. The customer is shown Payment Page embedded in the page of the web service. 7. The customer enters required data and confirms payment the way it is configured in the web service. 8. The web service calls the `trySubmit` method of the `EPayWidget` object for initial validation of entered data. 9. The data provided by the customer is validated on the side of Payment Page. 10. Using the `onCheckSubmit` function, Payment Page sends to the web service the confirmation that payment processing can be initiated and that the payment needs confirmation by the customer. 11. The web service calls the `resolve` method of the `onCheckSubmit` function following which information about payment confirmation is sent to Payment Page. 12. The web service invokes the `onShowLoader` function to display the preloader to the customer. 13. The web service preloader page is displayed to the customer. 14. The request for processing a payment is sent to the payment platform. 15. The payment platform processes the request and sends it to the payment environment. 16. The purchase is processed in the payment environment. 17. The payment environment sends a notification about the result to the payment platform. 18. The payment platform sends the result information to Payment Page. 19. The web service invokes the `onHideLoader` function to hide the preloader and show the payment form to the customer. 20. The result information is displayed to the customer on Payment Page. ## Setup and testing {#section_zxq_q2g_l3c .section} To start working with Payment Page in embedded mode: 1. If you have not yet finalised organisational steps that need to be taken towards integration with Ecommpay, take necessary actionby signing up and providing required information \([details](en_pp_interaction_organisation.md#)\). 2. If you have not yet carried out the work for integrating Payment Page with the use of specialised libraries, do so by taking the following steps: 1. On the client side, add the Ecommpay CSS and JavaScript librariesavailable at `https://paymentpage.ecommpay.com/shared/merchant.css` and `https://paymentpage.ecommpay.com/shared/merchant.js`. ``` {#codeblock_c31_yrr_c3c .language-xml} ``` **Warning:** Note that you must link the Ecommpay CSS and JavaScript libraries via the CDN \(Content Delivery Network\).Storing these libraries locally can lead to critical errors in the payment form's behaviour. 2. Configure the Content Security Policy by specifying the source URLs required for correct operation of the payment form in the `Content-Security-Policy` HTTP header \([details](en_pp_interaction_organisation.md#section_jth_vnh_qjc)\). ``` {#codeblock_ejr_n4k_mjc} Content-Security-Policy: script-src https://paymentpage.ecommpay.com https://applepay.cdn-apple.com; style-src https://paymentpage.ecommpay.com; img-src https://applepay.cdn-apple.com; frame-src https://paymentpage.ecommpay.com https://applepay.cdn-apple.com ``` 3. On the server side, set up collection and signing data passed in the requests for opening Payment Page \(you can automate the following [algorithms](en_platform_signature.md#) or use [one of the specialised SDKs](en_sdk_overview.md#section_vcj_5zv_tvb)\) and sending signed data to the client side of the web service. 3. On the client side, take all necessary steps to ensure the web service can work with the embedded mode of Payment Page: 1. Implement the HTML element to display the form. ``` {#codeblock_kpz_1sr_c3c .language-xml}
``` 2. Implement invoking the payment form using the JavaScript library from Ecommpay and the `EPayWidget.runEmbedded` method \(more below\). 3. Implement declaring functions for handling interface events \(more below\). 4. If necessary, agree upon the fields displayed on the form and enabling the capabilities with your Ecommpay account manager. You can configure the following: - Removing the field for entering the name of the cardholder, on the condition that each request for opening the payment form will contain parameters `customer_first_name` and `customer_last_name` \(subsequently you can populate this field with the data passed in the requests for opening the payment form\). Alternatively, you can avoid collecting cardholder data and accept the risk of possible decrease in payment acceptance rates. - Displaying additional fields for collecting customer data, for example, their emails and phone numbers, \([details](en_PP_Gathering_customer_data.md)\). - Enabling your customers to save card details, subsequently use them to pay, or remove themwhen they use the payment form \(this option is available by default, but it can be disabled\). 5. If necessary, you can customise the appearance of the payment form using the **Payment Page Designer**in Dashboard \([details](en_PP__design_customisation.md#)\). 6. Once you have set up, you can test payment processing using test card details and test projects \([details](en_test_cards.md)\) and proceed to taking real payments. If you have any questions about working with the platform using the Payment Page embedded mode, refer to this documentation as well as your account manager and the Ecommpay technical support. ## Using callback functions {#section_cw5_fxp_l3c .section} Using Payment Page in embedded mode involves using callback functions that are declared by the web service when invoking the form. To ensure correct payment processing, invoke the `onCheckSubmit` function. In addition, you can use other functions: - `onShowLoader`—for displaying the web service preloader - `onHideLoader`—for hiding the web service preloader\(if it is necessary to display the payment form pages to the customer\) - `onPaymentSubmitResult`—for receiving information about the request identifier - `onPaymentFail`— for receiving information about the payment decline - `onPaymentSuccess`—for receiving information about the payment completion - `onError`—for receiving information about errors on the payment form side **Note:** Use the `onPaymentFail` and `onPaymentSuccess` functions as the primary mechanism for handling payment results as well as for initiating redirection of a customer to a corresponding page of the web service if the `redirect_success_url` parameter is not used for this purpose \([details](en_pp_microframe_solution.md#section_ick_qhq_l3c)\). There is no need to redirect the customer to a separate preloader page or repeatedly check the payment status from your backend — Payment Page checks the status directly and sends the corresponding callback once a final payment result is received. In addition, other relevant functions can be usedto handle interface events \([details](en_pp_ui_monitoring.md#)\). The following is the example of invoking necessary functions on the client side of the web service. ``` {#codeblock_psg_fqr_c3c .language-javascript} const checkoutButtonsWidget = EPayWidget.runEmbedded({ ...configObj, // Declaring the function for showing the web service preloader onShowLoader: merchantPage.showMerchantLoader, // Declaring the function for hiding the web service preloader onHideLoader: merchantPage.hideMerchantLoader, // Declaring the function for receiving information about the payment completion // and for subsequent redirection of the customer onPaymentSuccess: function (data) { merchantPage.redirectToSuccessPage(); }, // Declaring the function for receiving information about the payment decline // and for displaying the corresponding message to the customer onPaymentFail: function (data) { merchantPage.showPaymentFailMessage(); }, // Declaring the function for validating the payment request onCheckSubmit: async function (data, resolve, reject) { try { // Validating the order if (!await merchantPage.validateCheckoutPage()) { return reject() // Rejecting due to incorrect order contents } if (!await merchantAPI.validateCartAmount(checkoutButtonsWidget.configObj.payment_amount, checkoutButtonsWidget.configObj.payment_currency)) { return reject() // Rejecting due to errors with the amount and currency of the payment } // Registering the order on the side of the web service const { orderId, additionalParameters } = await merchantAPI.placeOrder(merchantPage.cart, merchantPage.customerInfo); if (!orderId) { return reject() // Rejecting due to errors occurred in the process of registering the order } // Confirming payment by the web service with additional information return resolve({ additional_parameters: additionalParameters}); } catch (error) { console.error('onCheckSubmit error:', error); return reject(); } }, // Declaring the function for receiving information about the request registration in the payment platform onPaymentSubmitResult: async function (data) { await merchantAPI.saveTransactionId(orderId, data.request_id) }, // Declaring the function for displaying error messages to customers onError: async function ({ messages }) { await merchantAPI.log("Payment error occurred " + messages) if (messages.includes("invalid payment_id")) { merchantPage.redirectToContactSupportPage(); } }, }, 'POST'); // Invoking the trySubmit function when the customer confirms the payment (by clicking the button) document.getElementById('placeOrderBtn').addEventListener('click', function() { checkoutButtonsWidget.trySubmit(); }); ``` ## Use {#section_jzt_pzp_l3c .section} In general, to process a payment using Payment Page in embedded mode, the following is required on the web service side. 1. Generate a request to open the payment form. The request must contain the `configObj` JavaScript object with [the parameters for invoking the payment form](en_pp_embedded_payment_buttons.md#) and [the signature](en_platform_signature.md#) for them. The essential data set required for processing a paymentin this case includes: - `target_element`—identifier of the iframe elementin which the payment form should be opened - `payment_id`—payment identifierunique within the project - `payment_amount`—payment amountin the smallest currency unit - `payment_currency`—payment currency codein the ISO-4217 alpha-3 format - `project_id`—project identifierobtained from Ecommpay during integration - `merchant_domain`—domain name of the web service in which the payment form should be opened - `force_payment_method`—code of the payment methodthat will be shown as preselected, with `card` passed as a value - `mode`—Payment Page operation mode indicator with the value `purchase` for any of the one-time purchases and `card_verify` for card verification - `signature`—request signaturegenerated after all target parameters are specified ``` {#codeblock_nhw_3tr_c3c .language-json} const configObj = { target_element: "widget-container-card-embedded", payment_id: "X03937", payment_amount: 1960, payment_currency: "EUR", project_id: 22, merchant_domain: "cosmoshop.jupiter.example", force_payment_method : "card", signature: "0ByxpQ30hfTIjaCCsVIwVyabcDEF123" }; ``` 2. Invoke the payment form using the `EPayWidget.runEmbedded` method, specifying the `configObj` JavaScript object and functions`onCheckSubmit`, `onShowLoader`, and `onHideLoader` \(more below\). 3. When the customer confirms the intent to pay, for example by clicking the button,invoke the `trySubmit` method of `EPayWidget`. As a result, on the Payment Page side, the initial verification of payment information is performed following which one of the two functions is invoked automatically: - `onCheckSubmit`—if there are no errors, without anything specified in the `data` object - `onValidationError`—if there are errors, with information about these errors specified in the `data` object ``` {#codeblock_nsp_4rw_c3c .language-json} "{\"message\":\"epframe.embedded_mode.validation_error\",\"data\":{\"pan\":\"Invalid card number.\",\"month_year\":\"Expiry date required.\",\"cvv\":\"CVV2/CVC2 required.\",\"card_holder\":\"Cardholder name required.\"},\"guid\":\"288d-f68c-e53d-3890\"}" ``` 4. Verify payment information \(such as the payment amount and currency as well as other required data\)and call one of these functions: - `resolve`—to confirm the payment\(if there are no errors\) - `reject`—to decline the payment\(if there are errors\) Along with the payment confirmation, at this stage you can pass the customer information\(if it was not passed when the payment form was initialised or if it needs to be changed\) as well as specify URLs for automatic customer redirection once the payment is complete. For this, use the `additional_parameters` object. ``` {#codeblock_rv4_xyr_c3c .language-json} { // General customer information customer_id:"customer_112", customer_first_name:"Arthur", customer_last_name:"McDonald", customer_phone:"447700900123", customer_email:"mcdonald@space.com" // Customer's address customer_country:"GB", customer_city:"Belfast", customer_address:"14A Cosmos Crescent, Flat 25", customer_zip:"BT99 0ZZ", // Customer's billing address billing_country:"GB", billing_city:"Belfast", billing_address:"14A Cosmos Crescent, Flat 25", billing_postal:"BT99 0ZZ", // Customer's address for the AVS check avs_street_address:"14A Cosmos Crescent, Flat 25", avs_post_code:"BT99 0ZZ", // Customer's redirection information redirect_success_url:"https://cosmoshop.jupiter.example/pages/success", redirect_success_mode:"parent_page", redirect_fail_url:"https://cosmoshop.jupiter.example/pages/failed", redirect_fail_mode:"parent_page" } ``` ## Parameters {#section_ick_qhq_l3c .section} The following parameters can be used for opening the payment form in embedded mode. |Parameter|Description| |---------|-----------| |`avs_post_code` string, optional |The postal code of the customer to be used in the [Address Verification Service](en_PP_avs.md) check. Example: `BT99 0ZZ` | |`avs_street_address` string, optional |The address of the customer to be used in the [Address Verification Service](en_PP_avs.md) check. Consists of a house number and a street name. Example: `14A Cosmos Crescent, Flat 25` | |`billing_address` string, optional |The name of the street and the house number\(including any additional parts of the address such as building indicators\) in the customer's billing address. Example: `14A Cosmos Crescent, Flat 25` | |`billing_city` string, optional |The name of the city in the customer's billing address. Example: `Belfast` | |`billing_country` string, optional |The country code in the customer's billing address. Specified in the ISO 3166-1 alpha-2 format. Example: `GB` | |`billing_postal` string, optional |The postal code in the customer's billing address. Example: `BT99 0ZZ` | |`customer_address` string, optional |The name of the street and the house number\(including any additional parts of the address such as building indicators\) in the customer's address, separated by a comma. The length of the string cannot be more than 255 characters. Example: `14A Cosmos Crescent, Flat 25` | |`customer_city` string, optional |The name of the city \(or other settlement type\) in the customer's address. The length of the string cannot be more than 255 characters. Example: `Belfast` | |`customer_country` string, optional |The country code in the customer's address. Specified in the ISO 3166-1 alpha-2 format. Example: `GB` | |`customer_email` string, optional |The email address of the customer. The length of the string cannot be more than 255 characters. The string consists of a local-part and a domain name, separated by the `@` symbol. Example: `mcdonald@space.com` | |`customer_first_name` string, optional |The first name of the customer. The length of the string cannot be more than 255 characters. Example: `Arthur` | |`customer_id` string, optional |The identifier assigned to the customer within the scope of the project\(specified in `project_id`\). Each web service account should be linked to only one identifier and vice versa. This requirement is intended to address various risks and fraudulent operations. Example: `customer_112` | |`customer_last_name` string, optional |The last name of the customer. The length of the string cannot be more than 255 characters. Example: `McDonald` | |`customer_phone` string, optional |The phone number of the customer. Generally, should include the country code; however, some cases do not require a country code to be specified. Should contain between four and 24 digits. Example: `447700900123` | |`force_payment_method` string, required |In case of processing payments via the Payment Page embedded mode, must be set to `card`. Example: `card` | |`merchant_domain` string, required |Domain name of the web service in which the payment form should be opened. Example: `cosmoshop.jupiter.example` | |`mode` string, required |Indicator that specifies the Payment Page operation mode. In case of processing payments with the use of buttons, must be set to `purchase` or `card_verify`. Example: `purchase` | |`operation_type` string, optional |Indicator that specifieswhether a purchaseis processed in one or two steps. Should be specified in cases where the intended payment type is different from the one specified by default \(with regard to the number of steps\). Can have one of the following values: - `sale`—for one-step purchases \(with the funds transferred to the merchant immediately;[details](en_pp_purchase.md)\) - `auth`—for two-step purchases \(with the funds transferred to the merchant after first being in an authorisation hold;[details](en_pp_purchase_auth.md)\) Example: `auth` | |`payment_amount` integer, required |The amount of the payment. Specified in the smallest currency unit without a decimal separator. Example: `1960`\(represents an amount of 19.60 currency units when referring to a currency with two decimals\) | |`payment_currency` string, required |Three-letter code of the payment currency. Specified in the ISO-4217 alpha-3 format, according to the [currency codes reference](en_currency_codes.md). Example: `EUR` | |`payment_id` string, required |The payment identifier. Must be assigned by the web service. Should consist of a string no longer than 255 characters, be case-insensitive, and correspond one-to-one with the relevant payment within that project. Example: `X03936` | |`project_id` integer, required |Identifier of the projectintended to manage the interactions of the web service with the payment platform. This identifier is assigned by Ecommpayduring the integration \([details](en_glossary.md#)\). Example: `22` | |`recurring` string, optional |Data of the COF purchase being registered \([details](en_pp_recurring.md)\). If the JavaScript library from Ecommpay is used, the data can be passed in the JSON objectthat can include any number of supported parameters. ``` {#codeblock_st1_lbb_j3c .language-json} { "register": true, "type": "U" } ``` | |`redirect_fail_mode` string, optional |Indicator that specifies the mode for the final redirection of the customer to the web service when the purchase is declined. Can have one of the following values: - `iframe`—opens the pagein an iframe object \(this value is ignored if the payment form is opened in a new tab and the customer is redirected in that new tab\) - `parent_page`—opens the pagein the currently active tab - `blank_page`—opens the pagein a new tab Example: `parent_page` | |`redirect_fail_url` string, optional |URL for final redirection to the web service if the purchase is declined. Example: `https://cosmoshop.jupiter.example/pages/failed` | |`redirect_success_mode` string, optional |Indicator that specifies the mode for the final redirection of the customer to the web service when the purchase is completed. Can have one of the following values: - `iframe`—opens the pagein an iframe objectin which the payment form is opened - `parent_page`—opens the pagein the currently active tab - `blank_page`—opens the pagein a new tab Example: `parent_page` | |`redirect_success_url` string, optional |URL for final redirection to the web service by customer decision when a purchase is completed. Example: `https://cosmoshop.jupiter.example/pages/success` | |`signature` string, required |The digital signature used to sign the query parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified \([details](en_platform_signature.md#)\). | |`style_id` integer, optional |The identifier of the payment form design style. Can be used for working with different Payment Page design styles \([details](en_PP__design_customisation.md#)\). Example: `6123` | |`target_element` string, required |The iframe element identifier\(for the HTML page of the web service\) of the element where the payment form should be opened. Example: `widget-container-card-embedded` | ## Useful links {#section_asc_w4q_l3c .section} When working with the payment platform via Payment Page in embedded mode, you can use the following articles: - [Customisation](en_PP__design_customisation.md#)—an article about working with the **Payment Page Designer**. - [Collecting customer data](en_PP_Gathering_customer_data.md)—an article about the capability of collecting customer data. - [Payment retries](en_PP_Try_Again.md)—an article about the capability of payment retries. - [Signature generation and verification](en_platform_signature.md#)—an article about generating and verifying signatures in requests and callbacks for interaction with the payment platform. - [SDKs for data signing](en_sdk_overview.md#section_vcj_5zv_tvb)—information about using SDKs for data signing. - [Handling events in Payment Page](en_pp_ui_monitoring.md#)—an article about the capability of handling interface events of the payment form and related customer actions. - [Handling payment processing information](en_platform_payment_information.md)—a section on different ways to retrieve information that can be used for monitoring payment processing and analysing payment results. - [Test cards](en_test_cards.md)—an article with test card numbers that can be used for testing various payment processing scenarios. **Parent topic:**[Payment Page](en_PP_about.md) --- # UX configuration {#en_pp_ux_configuration} Articles about the primary workflows for the standard version of Payment Page, including options for opening it, handling redirects to third-party services and back to the web service, and managing these processes. The information about various options of the payment form UX configuration: - [Options for opening Payment Page](en_PP_Integration.md)—about the ways of opening the form, including its opening in a separate tab, modal window, and an iframe object. - [Options for redirecting customers to third-party services](en_PP_pm_redirect_mode.md)—about the ways of opening auxiliary pageswhen working with different payment methods. - [Options for redirecting customers to the web service](en_PP_redirect_modes.md#)—about the ways of redirecting customers from the payment form to the web service via the specified URLs. - **[Options for opening Payment Page](en_PP_Integration.md)** Articles about options for opening Payment Page: in a separate tab, a modal window, or an iframe. - **[Options for redirecting customers to third-party services](en_PP_pm_redirect_mode.md)** An article about options for opening third-party auxiliary pages across different payment methods. - **[Options for redirecting customers to the web service](en_PP_redirect_modes.md#)** An article about options for redirecting customers from the payment form to the web service using the specified URLs. **Parent topic:**[Payment Page](en_PP_about.md) --- # Options for opening Payment Page {#en_PP_Integration .concept} Articles about options for opening Payment Page: in a separate tab, a modal window, or an iframe. There are different options to open the Payment Page payment form on customers' devices: in a separate browser tab, in a modal window, and directly on the web service page—in an iframe element. These options are managed on the web service side, and when they are set up, various factors can be considered: for example, the payment form can be set up in such a way that on mobile devices it opens in a separate browser tab, while on other devices it opens in a modal window. In order to configure the opening of Payment Page on the web service side in a way needed, address the general issues of [the interaction concepts](en_pp_interaction_organisation.md#) and refer to the articles of this subsection. - [Opening Payment Page as a separate HTML page](en_PP_method_NewTab.md#) - [Opening Payment Page in a modal window](en_PP_method_ModalWindow.md#) - [Opening Payment Page in an iframe element of an HTML page](en_PP_method_Embedded.md#) - **[Opening Payment Page as a separate HTML page](en_PP_method_NewTab.md#)** An article about opening Payment Page as a separate HTML page with the use of the JavaScript library from Ecommpay and in-house solutions. - **[Opening Payment Page in a modal window](en_PP_method_ModalWindow.md#)** An article about opening Payment Page in a modal window with the use of the JavaScript library from Ecommpay and in-house solutions. - **[Opening Payment Page in an iframe element of an HTML page](en_PP_method_Embedded.md#)** An article about opening Payment Page in an iframe element with the use of the JavaScript library from Ecommpay and in-house solutions. **Parent topic:**[UX configuration](en_pp_ux_configuration.md) --- # Options for redirecting customers to third-party services {#en_PP_pm_redirect_mode} An article about options for opening third-party auxiliary pages across different payment methods. ## Overview {#section_hhm_xvb_qkb .section} During payment processing, customer redirection from the payment form pages to the services of third parties, such as banks, payment systems, and providers, can be required. This can be necessary for customer authentication, payment confirmation by customers, and other actions.Customer redirection can look as follows. ![](images/ecommpay/en_pp_pm_redirect_mode_1.svg "Automatic redirection") ![](images/ecommpay/en_pp_pm_redirect_mode_2.svg "Click redirection") In the Ecommpay payment platform, various options for such redirections are supported: with the pages of the third-party services openedin an iframe object, in the current or in a new browser tab\(a new tab can be opened automatically or by the click of the button, with the forced redirection once the specified time period expires\).Depending on a payment methodand considering the special aspects of its use, one of these options is applied in the payment platform by default. At the same time, when setting up a method within a certain project, the merchant can coordinate the application of another option\(from the available ones\) with the technical support specialists. Finally, for individual payments, it is possible to select the option of redirection in a separate tab by using the parameters for opening Payment Page. ## Request format {#section_u3x_xxc_25b .section} If for a separate payment, it is required to specify the option of opening the page of a third-party service in a new browser tab, disregarding the option specified for the method in general, the request should contain the boolean parameter `force_acs_new_window` with the value `1`.\(Using this parameter with the value `0` does not affect the redirection options.\) In the following example of a request for purchase processing, the preselected method is Open Banking in Romania and the page of the bank Banca Comerciala Romana, which supports the purchase by using this method, is set to open in a separate tab. ```language-json { payment_id: "X03936", payment_amount: 1000, payment_currency: "EUR", project_id: 123, customer_id: "customer1", force_payment_method: "online-romanian-banks", payment_methods_option: { "online_romanian_banks": { "banks_id": [55941] } }, force_acs_new_window: 1, // the option of opening the bank page signature: "kUi2x9dKHAVNU0FYldJrxh4...zUCwX6R\/ekpZhkIQg==" } ``` ```language-json { payment_id: "X03936", payment_amount: 1000, payment_currency: "EUR", project_id: 123, customer_id: "customer1", force_payment_method: "online-romanian-banks", payment_methods_option: { "online_romanian_banks": { "banks_id": [55941] } }, force_acs_new_window: 1, // the option of opening the bank page signature: "kUi2x9dKHAVNU0FYldJrxh4...zUCwX6R\/ekpZhkIQg==" } ``` ## Related topics {#section_vvp_gyc_25b .section} When working with various customer redirections, the following articles can come in handy: - [Options for redirecting customers to the web service](en_PP_redirect_modes.md#)—with the information about customer redirections from the payment form pages to the web service. - [Methods](en_pm_about.md)—with the information about payment methods and the work with them. - [Payment Page API specification](en_PP_Parameters.md)—with the descriptions of parameters that can be used in requests for opening Payment Page. **Parent topic:**[UX configuration](en_pp_ux_configuration.md) --- # Basic actions {#en_pp_basic_actions} Articles about the core actions that can be performed via the payment form, with the description of user scenarios and relevant request and callback formats for standard card payments. The information about the basic actions that can be performed via the payment form, with the description of logical models, user scenarios, as well as the request and callback formats: - [Payment processing](en_platform_payment_model.md)—about the types of the payments that can be processed via Payment Page, payment workflows, as well as possible payment and operation statuses. - [Purchase processing](en_pp_purchase.md)—about processing purchases that result in immediate debiting of funds. - [Authorisation hold](en_pp_purchase_auth.md)—about placing a hold on funds within a two-step purchase. - [COF purchase registration](en_pp_recurring.md)—about registering purchases followed by a series of recurring debitis. - [Performing payouts](en_pp_payout.md)—about issuing payouts. - [Payment instrument verification](en_pp_account_verification.md)—about debiting of a zero amount or placing a hold on funds for validating the payment instrument. - [Tokenization](en_pp_token.md)—about opening the payment form for registering payment data and forming a token for this data. - **[Purchase processing](en_pp_purchase.md)** An article about processing via Payment Page one-time purchases with immediate debiting of funds. - **[Authorisation hold](en_pp_purchase_auth.md)** An article about placing a hold on funds via Payment Page as part of processing two-step purchases with subsequent debitings. - **[COF purchase registration](en_pp_recurring.md)** An article about registering via Payment Page purchases followed by a series of recurring debits. - **[Performing payouts](en_pp_payout.md)** An article about processing payouts via Payment Page. - **[Payment instrument verification](en_pp_account_verification.md)** An article about verifying a payment instrument via Payment Page by debiting a zero amount or placing a hold on funds. - **[Tokenization](en_pp_token.md)** An article about opening the payment form for registering payment data and generating a token for this data. **Parent topic:**[Payment Page](en_PP_about.md) --- # Purchase processing {#en_pp_purchase} An article about processing via Payment Page one-time purchases with immediate debiting of funds. **Note:** This article covers processing one-time one-step purchases via Payment Page and describes requests and callbacks that are used in case of card payments. In addition, use the following materials to gain a fuller understanding of processing one-time one-step purchases: - [One-time one-step purchase](en_platform_sms_model.md)—an article in the section [Payment processing](en_platform_payment_model.md) that provides a general description of processing one-time one-step purchases in the Ecommpay payment platform and covers information about operations utilised to execute a payment of this type and statuses that are assigned to the payment and the operations performed within it. - articles of the [Payment methods](en_pm_about.md) section containing a description of processing one-time one-step purchases via Payment Page with the focus on the specific features of the payment method used and information about relevant requests and callbacks. ## General information {#section_adl_53h_2mb .section} *One-step purchase*, or *one-time one-step purchase*, is a payment type which uses only one request to make a one-time transfer of funds from customer to merchant. Payment Page allows you to process one-step purchases by using payment cardsor alternative payment instruments including MO/TO \(Mail Order/Telephone Order\) purchases in which user submits card details through mail, phone, or any other means of communication. When adding a new payment card for purchase processing, its payment data is saved and a token associated with this card is generated if this option is available in the merchant project \(for more details, see [Tokenization](en_pp_token.md)\). These operations are performed in the Purchase operation mode of the payment form. **Warning:** In order to enhance the quality of payment processing and ensure compliance with industry standards, starting from January 15, 2026, merchants in certain business categories must specify the `booking_info` parameter containing information about the start and end dates of the booked service \([details](en_pp_additional_data.md#)\), for each initiated [card purchase](en_pm_cardpayments.md). This requirement applies to merchants with [Merchant Category Codes \(MCC\)](en_glossary.md#) 3000–3999, 4411, 4511, 4722, 5962, 6513, 7011, 7012, 7512, 7519, and 7922. In terms of processing one-time one-step purchases using Payment Page, the basic steps that the customer performs may be selecting payment instrument, specifying its details and waiting for notification about the payment processing result. ![](images/ecommpay/en_pp_purchase_1.svg) When processing one-time one-step purchases by using Payment Page, payment information can be specified as follows: - *On the payment form, by completing the fields.* In this case the customer completes all the fields on the payment form. In case of card payments, it is possible to make the field with the cardholder name optional instead of required. Note it can only be done upon consultation with your account manager which includes examination and assessment of associated risks\). - *On the payment form, with an option to use saved payment information.* If the customer's identifier is specified in the request for opening Payment Page, the customer can either choose one of the saved payment instruments or enter new payment information; the new payment instrument can also be saved for subsequent purchases. In addition to selecting payment information, for some payment instruments entering verification code is required \(such as CVC, CVV or CID for card payments\). - *Outside the payment form, with an option to use saved payment information.* In this case the customer selects specific card in the web service, the token of this card is specified in the request for opening the payment form, and, when the payment form is opened, it already contains all required payment information, except for verification code \(CVC, CVV, CID\) which the customer is required to enter on the payment form. ![](images/ecommpay/en_pp_purchase_2.svg) *Different options of specifying payment information on Payment Page: by completing the fields on the form, by selecting the saved payment instrument on the form and by selecting saved payment instrument before opening the payment form respectively.* ## Workflow {#section_bk5_1jh_2mb .section} In terms of processing one-step purchases by using Payment Page, the merchant web service is required to do the following: 1. Create and send a request for opening Payment Page to the payment platform. 2. Receive callback with the result of the request processing from the payment platform. One-step purchase processing may involve auxiliary procedures: - *3‑D Secure authentication*—the customer is forwarded to the service of the issuer where the customer needs to complete authentication using the code received by SMS or performing other required steps, or loading page is displayed \(while issuer confirms authentication with no customer effort required\). - *Customer authentication on merchant's request*, in terms of which an additional page is displayed and the customer needs to enter special verification code received by SMS or in a bank statement; this type of authentication involves a temporary hold of the agreed amount on the customer's account. This type of authentication can be used instead of 3‑D Secure authentication or in addition to it. - *Submission of additional payment information*, in terms of which a notification and additional fields to be completed are displayed on the payment form. The fields should be completed on the same page of the payment form. These procedures do not require any additional effort on the merchant's web service side, but usually require customer effort. The following sections cover information about request and callback formats to use when processing purchases by using payment cards. For more information about request and callback formats to use when processing purchases by using alternative payment methods, see [Methods](en_pm_about.md). ## Request format {#section_iqm_pxh_2mb .section} The format of the request for opening Payment Page to process one-step payments using payment cards is the same as the request format described in the [Request format](en_pp_interaction_organisation.md#) section. When creating request, you should consider the following: 1. The request body must contain the following required parameters: - `project_id`—the project ID obtained from Ecommpay. - `payment_id`—the payment ID unique within the project. - `customer_id`—the customer ID unique within the project. - `payment_amount`—payment amount in minor currency units. - `payment_currency`—payment currency code in the ISO-4217 alpha-3 format. - `signature`—the signature that is created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#). 2. When performing one-step purchase in a project that by default requires authorisation hold, you must additionally use the `operation_type`\([details](en_PP_Parameters.md)\) parameter set to `sale`; note that this parameter is not required in other operations. 3. To make sure that all required parameters are specified if the capability of collecting such customer data is not implemented \([details](en_PP_Gathering_customer_data.md)\), pass at least one of the following parameters in the request: `customer_email` or `customer_phone`. 4. If you need to have the payment form displayed with the payment card selected, specify the `account_token` parameter in the request for opening the payment form. In this parameter you need to specify token of the payment card associated with the payment information of the card on the side of the payment platform. 5. To display Payment Page in a required language, you need to additionally specify in the request the `language_code` parameter and the language code in accordance with ISO 639-1 alpha-2 as its value. If this parameter is not specified, the payment form is displayed in the language selected automatically \(by the browser language or by default—[learn more](en_PP_WigetLanguages.md)\). 6. To add description of the payment, you need to specify in the request the `payment_description` parameter. The value of this parameter is displayed to the customer on the page with information about the result and to the merchant in Dashboard and in a callback with information about the payment result. 7. To perform an MO \(Mail Order\) purchase, you must use the `moto_type` parameter set to `1`; for a TO \(Telephone Order\) purchase, you must add the `moto_type` parameter set to `2`. 8. If needed, you can also add any other additional parameters supported by Payment Page in the Purchase operation mode. The full list of parameters for opening Payment Page is provided in the [Payment Page API specification](en_PP_Parameters.md) section. Thus, a correct request for processing card payment must include project, customer and payment IDs, payment currency and amount and signature. Other parameters can also be specified in the request, but they are optional. ```language-json { "project_id": "42", "payment_id": "456789", "payment_currency": "USD", "payment_amount": "131970", "customer_id": "customer_12", "customer\_phone": "44991234567", "signature": "TSzdE5rJZaA9TYAKoGpfXriFf82MxF..." // when processing payment using preselected card: "account_token":"959c664ad6045679d71d89caff6c242a0..." } ``` ```language-json https://paymentpage.ecommpay.com/payment?payment_currency=USD&language_code=en&customer_id=customer_12&project_id=42&payment_amount=131970&payment_id=456789&signature=xxPURAKgVtgW4PY7QlbIdS5u7gdoXkhXvZB... ``` ## Callback format {#section_d42_ql3_2mb .section} The format of the callback to notify the merchant about the result of processing one-step purchase is the same as the format described in the [Handling callbacks](en_platform_callbacks.md#) section. The following is an example of callback with an information about successful `1 319,70 USD` purchase made by the customer `customer_12` using the payment card with the card number `431422******0056` in the project `42`. ```language-json { "account": { "number": "431422******0056 ", "token": "f365bb1729f9b72fd9c09703a751c979f3becc679f29c3e35c91d18070d15654", "type": "visa", "card_holder": "JOHN SMITH", "id": 45678, "expiry_month": "08", "expiry_year": "2025" }, "customer": { "id": "customer_12", "phone": "44991234567" }, "payment": { "date": "2019-01-11T13:02:42+0000", "id": "456789", "method": "card", "status": "success", "sum": { "amount": 131970, "currency": "USD" }, "type": "purchase", "description": "" }, "project_id": 42, "operation": { "id": 969000002636, "type": "sale", "status": "success", "date": "2019-01-11T13:02:42+0000", "created_date": "2019-01-11T13:01:45+0000", "request_id": "c6eed1eb14c629b4ef20b3b8086d...d04132c34b0088cbc0be4667c", "sum_initial": { "amount": 131970, "currency": "USD" }, "sum_converted": { "amount": 131970, "currency": "USD" }, "provider": { "id": 408, "payment_id": "330157196", "date": "2019-01-11T13:02:32+0000", "auth_code": "", "endpoint_id": "612266625" }, "code": "0", "message": "Success", "eci": "07" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm..." } ``` The following is the example of a callback with information about one-step purchase declined due to incorrect card data input. ```language-json { "project_id": 42, "payment": { "id": "456789", "type": "purchase", "status": "decline", "date": "2019-01-11T14:11:33+0000", "method": "card", "sum": { "amount": 131970, "currency": "USD" }, "description": "" }, "account": { "number": "431422******0056 ", "type": "visa", "card_holder": "JOHN SMITH", "expiry_month": "08", "expiry_year": "2025" }, "customer": { "id": "customer_12", "phone": "44991234567" }, "operation": { "id": 13300000004505, "type": "sale", "status": "decline", "date": "2019-01-11T14:11:33+0000", "created_date": "2019-01-11T14:11:00+0000", "request_id": "c6eed1eb14c629b4ef20b3b8086d...d04132c34b0088cbc0be4667c", "sum_initial": { "amount": 131970, "currency": "USD" }, "sum_converted": { "amount": 131970, "currency": "USD" }, "provider": { "id": 12, "payment_id": "48219213050", "auth_code": "", "endpoint_id": 12 }, "code": "10102", "message": "Incorrect data entered", "eci": "05" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm..." } ``` **Parent topic:**[Basic actions](en_pp_basic_actions.md) --- # Authorisation hold {#en_pp_purchase_auth} An article about placing a hold on funds via Payment Page as part of processing two-step purchases with subsequent debitings. **Note:** This article covers placing an authorisation hold via Payment Page as part of processing one-time two-step purchases and describes requests and callbacks that are used in case of card payments. In addition, use the following materials to gain a fuller understanding of processing one-time two-step purchases: - [One-time two-step purchase](en_platform_dms_model.md)—an article in the section [Payment processing](en_platform_payment_model.md) that provides a general description of processing one-time two-step purchases in the Ecommpay payment platform and covers information about operations utilised to execute a payment of this type and statuses that are assigned to the payment and the operations performed within it. - articles of the [Payment methods](en_pm_about.md) section containing a description of processing one-time two-step purchases via Payment Page with the focus on the specific features of the payment method used and information about relevant requests and callbacks. ## General information {#section_zsg_zr3_2mb .section} *Two-step purchase*, or *one-time two-step purchase*, is a payment type which uses two steps to make a one-time transfer of funds from customer to merchant. On the first step, merchant initiates an authorisation hold—in other words, the purchase amount is deducted from the credit limit of customer's card account. On the second step, the purchase amount is “captured,” or, in other words, it is transferred to the merchant account based on the merchant request or after specific time lag. **Note:** If the payment form is opened for initiating an authorisation hold \(with `auth` specified in the `operation_type` parameter\), the customer will be shown only those payment methods that support two-step purchases \([details](en_pm_about.md)\). Payment Page allows you to apply authorisation hold which in fact is the first step of this purchase type; authorisation hold is also available for MO/TO \(Mail Order/Telephone Order\) purchases. To apply an authorisation hold, you use the Purchase operation mode. **Warning:** In order to enhance the quality of payment processing and ensure compliance with industry standards, starting from January 15, 2026, merchants in certain business categories must specify the `booking_info` parameter containing information about the start and end dates of the booked service \([details](en_pp_additional_data.md#)\), for each initiated [card purchase](en_pm_cardpayments.md). This requirement applies to merchants with [Merchant Category Codes \(MCC\)](en_glossary.md#) 3000–3999, 4411, 4511, 4722, 5962, 6513, 7011, 7012, 7512, 7519, and 7922. In terms of performing the first step of the one-time two-step purchase using Payment Page, the basic steps that the customer performs may be selecting payment instrument, specifying payment details and waiting for notification about payment processing result. ![](images/ecommpay/en_pp_purchase_auth_1.svg) To perform the second step \(withdrawal or release of funds\), the merchant needs to use [Gate](en_gate_payment_auth.md#)or [Dashboard](en_dbl_about.md) or configure automatic performance of this step after a specific time lag. In order to configure automatic withdrawal or release of funds, contact Ecommpay technical support \([support@ecommpay.com](mailto:support@ecommpay.com)\). In terms of performing authorisation hold, payment information can be specified as follows: - *On the payment form, by completing the fields.* In this case the customer completes all the fields on the payment form. In case of card payments, it is possible to make the field with the cardholder name optional instead of required. Note it can only be done upon consultation with your account manager which includes examination and assessment of associated risks\). - *On the payment form, with an option to use saved payment information.* If the customer's identifier is specified in the request for opening Payment Page, the customer can either choose one of the saved payment instruments or enter new payment information; the new payment instrument can also be saved for subsequent purchases. In addition to selecting payment instrument, for some payment instruments entering verification code is required \(such as CVC, CVV, or CID for card payments\). - *Outside the payment form, with an option to use saved payment information.* In this case the customer selects specific card in the web service, the token of this card is specified in the request for opening the payment form, and, when the payment form is opened, it already contains all required payment information, except for verification code \(CVC, CVV, CID\) which the customer is required to enter on the payment form. ![](images/ecommpay/en_pp_purchase_auth_2.svg) *Different options of specifying payment information on Payment Page: by completing the fields on the form, by selecting the saved payment instrument on the form and by selecting saved payment instrument before opening the payment form respectively.* ## Time limit for authorisation hold {#section_hgy_djl_ylb .section} According to the requirements of Visa, Mastercard, and American Express, the time lag for holding funds is limited. For different types of cards the maximum allowed time lag is defined according to the following terms: - Visa cards: 1. If authorisation hold is performed as a part of COF purchase processing, the maximum allowed time lag is 5 days. 2. If authorisation hold is performed not as a part of COF purchase processing or COF purchase registration, and the merchant's Merchant Category Code \(MCC\) corresponds to one of the numbers: 3351–3500, 3501–3999, 4411, 7011, 7512, 7513, the maximum allowed time lag is 30 days. 3. In other cases the maximum allowed time lag is 10 days. - Maestro and Cirrus cards: the maximum allowed time lag is 6 days. - OtherMastercard cards: the maximum allowed time lag is 28 days. - American Express cards: 1. If merchant MCC is associated with hotel industry, car rental, or cruise lines the allowed time lag may extend to the entire duration of stay at a hotel, car rent duration or cruise duration, accordingly. 2. In other cases the maximum allowed time lag is 7 days. The maximum allowed time lag for holding funds is calculated starting from the moment the `auth` operation is created in the Ecommpay payment platform. 30 minutes before the time lag expires, depending on the parameters specified by the Ecommpay employees, one of the following operations is performed automatically: a withdrawal \(`capture`\) or a release \(`cancel`\) of the held funds, after that a callback is sent to the web service. For more information and configuration of the operation type you can refer to your Ecommpay key account manager.There is an exception for American Express cards for which the maximum allowed time lag is limited by the entire duration of stay at a hotel, car rent duration or cruise duration—automatic withdrawal is not available for such cards. If the time lag specified by the merchant for automatic withdrawal or release of funds exceeds the maximum allowed time lag, withdrawal or release of funds is performed according to the maximum allowed time lag.For instance, if the merchant configures automatic release of the held funds upon the expiration of 10 days and authorisation hold is performed by using Maestro card \(the maximum allowed time lag for Maestro card is 6 days\), automatic release of funds is performed upon the expiration of 6 days. ## Workflow {#section_msm_c1h_2mb .section} In terms of authorisation hold by using Payment Page, the merchant web service is required to do the following: 1. Create and send a request for opening Payment Page to the payment platform. 2. Receive a callback with information about the result of the request processing from the payment platform. Authorisation hold performing may involve additional procedures: - *3‑D Secure authentication*, in terms of which the customer is transferred to the service of the issuer where the customer needs to complete authentication using the code received by SMS or performing other required steps, or loading page is displayed \(while issuer confirms authentication with no customer effort required\). - *Customer authentication on merchant's request*, in terms of which an additional page is displayed and the customer needs to enter special verification code received by SMS or in a bank statement; this type of authentication involves a temporary hold of the agreed amount on the customer's account. This type of authentication can be used instead of 3‑D Secure authentication or in addition to it. - *Submission of additional payment information*, in terms of which notification and additional fields to be completed are displayed on the payment form. The fields should be completed on the same page of the payment form. The following sections cover information about request and callback formats to use when performing authorisation hold using payment cards. For information about request and notification formats when performing authorisation hold using alternative payment methods, see [Methods](en_pm_about.md). ## Request format {#section_pyb_xph_2mb .section} The format of the request for opening Payment Page to perform authorisation hold is the same as the request format described in the [Request format](en_pp_interaction_organisation.md#) section. When creating request, you should consider the following: 1. The request must contain the following required parameters: - `operation_type`—operation type for payment processing\([details](en_PP_Parameters.md)\). The parameter value must be set to *auth*, if purchases for the project are enabled by merchant request. - `project_id`—the project ID obtained from Ecommpay. - `payment_id`—the payment ID unique within the project. - `payment_amount`—payment amount in minor currency units. - `payment_currency`—payment currency code according to ISO-4217 alpha-3. - `customer_id`—the customer ID unique within the project. - `signature`—the signature created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#). 2. To make sure that all required parameters are specified if the capability of collecting such customer data is not implemented \([details](en_PP_Gathering_customer_data.md)\), pass at least one of the following parameters in the request: `customer_email` or `customer_phone`. 3. If you need to have the payment form displayed with the payment card selected, specify the `account_token` parameter in the request for opening the payment form. In this parameter you need to specify token of the payment card associated with the payment information of the card on the side of the payment platform. 4. To display Payment Page in a required language, you need to additionally specify in the request the `language_code` parameter and the language code in accordance with ISO 639-1 alpha-2 as its value. If this parameter is not specified, the payment form is displayed in the language selected automatically \(by the browser language or by default—[learn more](en_PP_WigetLanguages.md)\). 5. To add description of the payment, you need to specify in the request the `paymentDescription`parameter. The value of this parameter is displayed to the customer on the page with information about the result and to the merchant in Dashboard and in a callback with information about the payment result. 6. To perform an MO \(Mail Order\) purchase, you must use the `moto_type` parameter set to `1`; for a TO \(Telephone Order\) purchase, add the `moto_type` parameter set to `2`. 7. If needed, you can also add any other additional parameters supported by Payment Page in the Purchase operation mode. The full list of parameters for opening Payment Page is provided in the [Payment Page API specification](en_PP_Parameters.md) section. Thus, a correct payment request must include project, customer and payment IDs, language code, currency and the amount of a payment in the appropriate currency, the `auth` operation type and signature. Other parameters can also be specified in the request, but they are optional. ```language-json { "operation_type": "auth", "project_id": 42, "payment_id": "456789", "customer_id": "customer_12", "payment_currency": "USD", "payment_amount": "2000", "customer\_phone": "44991234567", "signature": "TSzdE5rJZaA9VyJtnfRI3620jOp2hf4RKwmKoWYjTYAK2MxF...", // when processing payment using preselected card: "account_token":"959c664ad64b8caa54bb7836ddc737fd1a679242a039..." } ``` ```language-json https://https://paymentpage.ecommpay.com/payment?payment_currency=USD&language_code=en&project_id=42&payment_amount=2000&payment_id=456789&operation_type=auth&signature=xxPURAKgVtgW4PY7QlbIdS5u7gdoXkhZLxEzkgcoZr... ``` ## Callback format {#section_j4p_lh3_2mb .section} The format of the callback to notify the merchant about the result of performing authorisation hold is the same as the format described in the [Handling callbacks](en_platform_callbacks.md#) section. The following is an example of callback with an information about successful authorisation hold of `2 000,00 USD` made for the customer `customer_12` using the payment card with the card number `541333******0019` in terms of the project `42`. ```language-json { "project_id": 42, "customer": { "id": "customer_12", "phone": "44991234567" }, "payment": { "id": "456789", "type": "purchase", "status": "awaiting capture", "date": "2019-01-11T13:00:40+0000", "method": "card", "sum": { "amount": 200000, "currency": "USD" }, "description": "" }, "account": { "number": "541333******0019", "type": "mastercard", "card_holder": "JOHN SMITH", "expiry_month": "08", "expiry_year": "2025" }, "operation": { "id": 2777000002350, "type": "auth", "status": "success", "date": "2020-01-11T13:00:40+0000", "created_date": "2020-01-11T13:00:37+0000", "request_id": "e2fd233d27c064fbe01af291039e6478341a0489-3...9", "sum_initial": { "amount": 200000, "currency": "USD" }, "sum_converted": { "amount": 200000, "currency": "USD" }, "provider": { "id": 120, "payment_id": "224750650", "date": "2020-01-11T13:00:39+0000", "result_code": "000", "result_message": "Approved", "auth_code": "505050", "endpoint_id": 120 }, "code": "0", "message": "Success", "description": "SUCCESS", "eci": "00" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm..." } ``` The following is the example of a callback with information about authorisation hold declined due to incorrect input of the expiration date of the payment card. ```language-json { "project_id": 42, "customer": { "id": "customer_12", "phone": "44991234567" }, "payment": { "id": "456789", "type": "purchase", "status": "decline", "date": "2020-01-11T13:00:40+0000", "method": "card", "sum": { "amount": 200000, "currency": "USD" }, "description": "" }, "account": { "number": "541333******0019", "type": "mastercard", "card_holder": "JOHN SMITH", "expiry_month": "08", "expiry_year": "2025" }, "operation": { "id": 6304000002973, "type": "auth", "status": "decline", "date": "2020-01-11T13:00:40+0000", "created_date": "2019-01-11T13:00:34+0000", "request_id": "63821f1e49b2b289d1dee0552082ed60b4108175-5...c", "sum_initial": { "amount": 200000, "currency": "USD" }, "sum_converted": { "amount": 200000, "currency": "USD" }, "provider": { "id": 120, "payment_id": "239689120", "date": "2020-01-11T13:00:36+0000", "result_code": "101", "result_message": "Decline, expired card", "auth_code": "", "endpoint_id": 120 }, "code": "10106", "message": "Card expired", "description": "Bank cards. Operation was declined due to incorrect card expiry date entry", "eci": "00" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm..." } ``` The following is an example of callback with an information about withdrawal of the held `2 000,00 USD` from the payment card with the card number `541333******0019` of the customer `customer_12` in terms of the project `42`. ```language-json { "project_id": 42, "payment": { "id": "456789", "type": "purchase", "status": "success", "date": "2020-01-11T15:54:40+0000", "method": "card", "sum": { "amount": 200000, "currency": "USD" }, "description": "" }, "account": { "number": "541333******0019", "type": "mastercard", "card_holder": "JOHN SMITH", "expiry_month": "08", "expiry_year": "2025" }, "customer": { "id": "customer_12", "phone": "44991234567" }, "operation": { "id": 7178000006597, "type": "capture", "status": "success", "date": "2020-01-11T15:54:40+0000", "created_date": "2019-01-11T15:54:39+0000", "request_id": "d066dfd72443584e1a35bb5eed60415aeb15ccfa-1...0", "sum_initial": { "amount": 200000, "currency": "USD" }, "sum_converted": { "amount": 200000, "currency": "USD" }, "provider": { "id": 120, "payment_id": "227307324", "date": "2020-01-11T15:54:40+0000", "auth_code": "919372", "endpoint_id": 120 }, "code": "0", "message": "Success" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm..." } ``` The following is an example of callback with an information about cancelling authorisation hold of `2 000,00 USD` for the payment card with the card number `541333******0019` of the customer `customer_12` in terms of the project `42`. ```language-json { "project_id": 42, "payment": { "id": "456789", "type": "purchase", "status": "canceled", "date": "2020-01-11T15:54:40+0000", "method": "card", "sum": { "amount": 200000, "currency": "USD" }, "description": "" }, "account": { "number": "541333******0019", "type": "mastercard", "card_holder": "JOHN SMITH", "expiry_month": "08", "expiry_year": "2025" }, "customer": { "id": "customer_12", "phone": "44991234567" }, "operation": { "id": 18289000007021, "type": "cancel", "status": "success", "date": "2020-01-11T15:54:40+0000", "created_date": "2020-01-11T15:54:40+0000", "request_id": "25cdabfad200b82bf6740d6a8d01818c6e64804e-1...c", "sum_initial": { "amount": 200000, "currency": "USD" }, "sum_converted": { "amount": 200000, "currency": "USD" }, "provider": { "id": 120, "payment_id": "239672146", "auth_code": "", "endpoint_id": 120 }, "code": "0", "message": "Success" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm..." } ``` The following is the example of a callback with information about authorisation hold declined due to incorrect card data input. ```language-json { "account": { "number": "541333******0019", "type": "mastercard", "card_holder": "JOHN SMITH", "expiry_month": "08", "expiry_year": "2025" }, "customer": { "id": "customer_12", "phone": "44991234567" }, "payment": { "date": "2020-01-11T15:54:40+0000", "id": "456789", "method": "card", "status": "decline", "sum": { "amount": 10000, "currency": "USD" }, "type": "purchase", "description": "" }, "project_id": 42, "operation": { "id": 18397000002376, "type": "cancel", "status": "decline", "date": "2020-01-11T15:54:40+0000", "created_date": "2020-01-11T15:54:35+0000", "request_id": "7482145798366de3166bedd372552b3f0094eed2-6...3", "sum_initial": { "amount": 10000, "currency": "USD" }, "sum_converted": { "amount": 10000, "currency": "USD" }, "provider": { "id": 120, "payment_id": "248013808", "date": "2020-01-10T22:37:10+0000", "auth_code": "876856", "endpoint_id": 120 }, "code": "10102", "message": "Incorrect data entered" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm..." } ``` **Parent topic:**[Basic actions](en_pp_basic_actions.md) --- # COF purchase registration {#en_pp_recurring} An article about registering via Payment Page purchases followed by a series of recurring debits. **Note:** This article that covers registering COF purchases via Payment Page and describes requests and callbacks that are used in case of card payments. In addition, use the following materials to gain a fuller understanding of processing COF purchases: - articles [On-demand COF purchase](en_platform_recurring_model.md) and [COF purchase with automatic debiting](en_platform_sheduled_recurring_model.md) in the section [Payment processing](en_platform_payment_model.md) that provide a general description of processing COF purchases in the Ecommpay payment platform and cover information about operations utilised to execute a payment of this type and statuses that are assigned to the payment and the operations performed within it. - articles of the [Payment methods](en_pm_about.md) section containing a description of COF purchase registration via Payment Page with the focus on the specific features of the payment method used and information about relevant requests and callbacks. ## General information {#section_bcf_1x3_2mb .section} The Ecommpay payment platform allows you to register COF purchases in a variety of ways by processing payments via Payment Page, Gate \([details](en_gate_payment_recurring_registration.md)\), and Dashboard \([details](en_dbl_payments.md#)\)as well as by migrating information about COF purchases and payment card tokens \([details](en_gate_data_migration.md#)\). This article covers information about registering COF purchases via Payment Page by performing one-time purchases and payment instrument verification. *Recurring purchase* is a payment type which uses only one request to make one \(recurring\) transfer of funds from customer to merchant. Recurring payments are processed by using previously stored payment credentials with no need for validation of the payment instrument \(such as card validation code, or CVC\). Support for COF purchases processing may be convenient when building lasting customer relationships when you would like to offer your customers an option to make purchases with no extra effort on their side. **Note:** If the payment form is opened for registering a COF purchase, the customer is shown only the payment methods that support registration of COF purchases \([details](en_pm_about.md)\). In terms of processing COF purchase registration using Payment Page, the basic steps that the customer performs may be selecting payment instrument, specifying its details and waiting for notification about the payment processing result. ![](images/ecommpay/en_pp_recurring.svg) The payment platform supports the following COF purchase types: - *OneClick purchases* are initiated by the customer and do not depend on any schedule or predetermined payment amount. For instance, the customer can make a one-click purchase in order to watch a movie online. - *Autopurchases* are initiated by merchant and do not depend on any schedule or predetermined payment amount. For example, when customer's mobile phone account balance falls below specific threshold, merchant may automatically top up the account. - *Regular purchases* are initiated by the merchant and are based on specific schedule and fixed amount. The schedule may be stored either on the payment platform side or in your web service. For instance, weekly payment for online subscription may be regularly debited to customer's account. Registration of any type of COF purchase requires customer's consent for storage of their payment information and its usage on certain terms. COF purchase is registered by using the Purchase and Card Verify operation modes. To initiate COF purchase processing, change its terms, cancel it, or to issue a refund, the merchant can use [Gate](en_Gate__payments_on_saved_data.md) \(for all types of COF purchases\) and [Dashboard](en_dbl_payments.md#) \(for regular COF purchases\). If there are changes in the payment provider's service settings, you may need to register COF purchase again. In such cases, the merchant receives an email from the Ecommpay technical support with a list of IDs of COF purchases that should be re-registered. For this registration, merchant must notify customers of the termination of previous debits and the need to initiate new ones by unlinking the saved card, and then initiate registration in the platform. Each newly registered COF purchase receives a new ID, which is sent to the merchant in the callback with information on successful registration. ## Workflow {#section_mgc_c2j_2mb .section} COF purchase registration by using Payment Page requires the merchant web service to do the following: 1. Create and send a request for opening Payment Page to the payment platform. 2. Receive callback with the result of the request processing from the payment platform. COF purchase registration may involve auxiliary procedures: - *3‑D Secure authentication*, in terms of which the customer is transferred to the service of the issuer where the customer needs to complete authentication using the code received by SMS or performing other required steps, or loading page is displayed \(while issuer confirms authentication with no user input required\). - *Customer authentication on merchant's request*, in terms of which an additional page is displayed and the customer needs to enter special verification code received by SMS or in a bank statement; this type of authentication involves a temporary hold of the agreed amount on the customer's account. This type of authentication can be used instead of 3‑D Secure authentication or in addition to it. - *Submission of additional payment information*, in terms of which notification and additional fields to be completed are displayed on the payment form. The fields should be completed on the same page of the payment form. These procedures do not require any additional effort on the merchant's web service side, but usually require customer effort. The following sections cover information about request and callback formats to use when registering COF purchases by using payment cards.For more information about request and callback formats to use when registering COF purchases by using alternative payment methods, see [Methods](en_pm_about.md). ## Request format {#section_hh4_ffj_2mb .section} The format of the request for opening Payment Page to register COF purchases is the same as the format described in the [Request format](en_pp_interaction_organisation.md#). When creating request, you should consider the following: 1. The basic minimum of parameters required for any payment must be specified: - `project_id`—project identifier obtained from Ecommpay - `payment_id`—payment identifier unique within the project - `customer_id`—customer identifier unique within the project - `payment_amount`—payment amount in the smallest currency unit \(to register COF purchases in terms of payment instrument verification, you need to specify the `0` value\) - `payment_currency`—payment currency code in the ISO-4217 alpha-3 format - `signature`—request signature generated after all required parameters were specified \(for more information, see the section [Signature generation and verification](en_platform_signature.md#)\) 2. For registering a COF purchase along with payment instrument verification, the `mode` parameter should be additionally specified. This parameter indicates the Payment Page operation mode and should have the `card_verify` value. 3. For specifying the properties of a COF purchase, the request should contain the `recurring` parameter as a JSON object—if the payment form is opened via the JavaScript library of Ecommpay—or as a string generated as a result of URL encoding—if the payment form is opened via another method. The `recurring` parameter must contain the main details about COF purchase registration: - `register`, boolean—indicator that specifies whether a COF purchase should be registered. - `type`, string—type of the COF purchase to register, possible values: - `C`—one-click purchase - `U`—autopurchase - `R`—regular purchase - `period`, string—frequency of debits \(for a regular COF purchase\), possible values: - `D`—daily - `W`—weekly - `M`—monthly \(if the set day is not available in the next month, for example, 31, the payment is performed on the last day of the month\) - `Q`—quarterly - `Y`—annually - `time`, string—time of performing subsequent debits \(for a regular purchase\) in `hh:mm:ss` format. The parameter is used if the `period` parameter is specified in the request. - `interval`, integer—multiplier to increase debiting frequency \(i.e. the interval of performing regular COF purchases\). This parameter is used in conjunction with the `period` parameter and should be assigned a numeric value from `1` to `100`. 4. For specifying the properties of a regular purchase, the `recurring` parameter can also contain other details: - `amount`, integer—fixed amount of subsequent debits in the smallest currency unit. - `start_date`, string—date on which the first debit operation is performed \(for a COF regular purchase\). This parameter is used in conjunction with the `scheduled_payment_id` parameter and should be specified in the `DD-MM-YYYY` format. - `expiry_day`, integer orstring—calendar day on which the specified duration period of the COF purchase will end \(the value should be provided as an integer from `1` to `31`, without a leading zero, in accordance with the Gregorian calendar\). - `expiry_month`, integer orstring—month in which the specified duration period of the COF purchase will end \(the value should be provided as an integer from `1` to `12`, without a leading zero, in accordance with the Gregorian calendar\). - `expiry_year`, integer—year in which the specified duration period of the COF purchase will end \(in the `YYYY` format, in accordance with the Gregorian calendar\). **Note:** If any of the parameters defining the expiry date of the COF purchase is not provided in the request, the following default values apply: - For standard card payments—the corresponding parameter value \(day, month, year\) is determined based on the expiry date of the specified payment card. - For other available methods—the corresponding parameter value is determined as follows: - Calendar day—the last calendar day of the relevant month \(as specified in the `expiry_month` parameter or corresponding to the COF purchase registration date\). - Month—the month in which the COF purchase was registered. - Year—the year that is 10 years after the year in which the COF purchase was registered. Accordingly, if only the year is specified, for standard card payments the day and month are taken from the expiry date of the relevant card and combined with the specified year. For an alternative payment method, the expiry date is set to the last calendar day of the month in which the COF purchase was registered and the specified year. - `scheduled_payment_id`, string—identifier assigned to the payment within which scheduled debits are performed. It must differ from the identifier of the payment made to register a COF purchase and must be unique within the project. Also, not to be confused with the debiting series record identifier specified in the `id` parameter of the `recurring` object that is passed in the callback with the COF purchase registration information. **Warning:** If the identifier that should be assigned to the COF purchase \(`scheduled_payment_id`\) matches the identifier of the payment made to register a COF purchase \(`payment_id`\), the request to register a COF purchase is declined. 5. To make sure that all required parameters are specified if the capability of collecting such customer data is not implemented \([details](en_PP_Gathering_customer_data.md)\), pass at least one of the following parameters in the request: `customer_email` or `customer_phone`. 6. For displaying the payment form to the customer in a specified language, the `language_code` parameter should be used with the language code specified in the ISO 639-1 alpha-2 format. If this parameter is not specified, the payment form is displayed in the language selected automatically \(by the browser language or by default—[learn more](en_PP_WigetLanguages.md)\). 7. For adding a payment description, the `payment_description` parameter can be used. The value of this parameter is a string displayed to the customer on the page with the information about the operation result and to the merchant in the Dashboard interface and sent to the merchant in the callback with information about the payment result. 8. Additionally, it is possible to use any other parameters available for the Purchase and Card Verify modes of the Payment Page operation. The full list of parameters for opening Payment Page is provided in the [Payment Page API specification](en_PP_Parameters.md) section. Thus, a request for COF purchases registration must include: - in terms of payment instrument verification—parameters for opening Payment Page for payment instrument verification and the `recurring` parameter with information about COF purchase registration. - in terms of purchase processing—parameters for opening Payment Page for processing a purchase and the `recurring` parameter with information about COF purchase registration. ``` {#codeblock_d5j_vjb_d2c .language-json} { "register": true, //COF purchase registration "type": "R", //regular purchase registrartion "amount": 400, "expiry_day": 1, "expiry_month": 8, "expiry_year": 2025, //last payment is scheduled for August 1, 2025 "interval": 10, "period": "D", //debiting every 10 days "time": "10:00:00", //debiting at 10:00:00 "start_date": "14-05-2019", "scheduled_payment_id": "A2323" } ``` ``` {#codeblock_kcs_vjb_d2c} "recurring": "%7B%22register%22%3Atrue%2C%22type%22%3A%22R%22%2C%22amount%22%3A400%2C%22 expiry_day%22%3A1%2C%22expiry_month%22%3A8%2C%22expiry_year% 22%3A2025%2C%22interval%22%3A10%2C%22period%22%3A%22D%22%2C% 22time%22%3A%2210%3A00%3A00%22%2C%22start_date%22%3A%2214-05-2019% 22%2C%22scheduled_payment_id%22%3A%22A2323%22%7D" ``` ``` EPayWidget.run( { payment_id: '567890', payment_amount: '400', customer_id: 'customer1', customer\_phone: '44991234567', payment_currency: 'USD', project_id: 42, force_payment_method: 'card', recurring: '{"register":true,"type":"R","amount":400,"expiry_day":1,"expiry_month":8,"expiry_year":2025,"interval": 10,"period":"D","time": "10:00:00","start_date":"14-05-2019","scheduled_payment_id":"A2323"}', signature: 'qlgcPujhcUcul5ZpMyR0%2BEtDUmSFJeLUCI1...' }, 'post') ``` ```language-json https://paymentpage.ecommpay.com/payment?signature=qlgcPujhcUcul5ZpMyR0%2BEtDUmSFJeLUCI1...&payment_id=567890&payment_amount=400&payment_currency=USD&project_id=42&customer_id=customer_1&customer_phone=44991234567&force_payment_method=card&recurring=%7B%22register%22%3Atrue%2C%22type%22%3A%22R%22%2C%22amount%22%3A400%2C%22expiry\_day%22%3A1%2C%22expiry\_month%22%3A8%2C%22expiry_year%22%3A2025%2C%22interval%22%3A10%2C%22period%22%3A%22D%22%2C%22time%22%3A%2210%3A00%3A00%22%2C%22start_date%22%3A%2214-05-2019%22%2C%22scheduled_payment_id%22%3A%22A2323%22%7D ``` ## Callback formats {#section_ys1_njj_2mb .section} The format of the callback to notify the merchant about the result of purchase processing or payment instrument verification with COF purchase registration is the same as the format described in the [Handling callbacks](en_platform_callbacks.md#) section. The following is an example of a callback with information about successful registration of COF purchase using the card `431422******0056`; COF purchase is registered for the customer `customer_10` in terms of the project `42`. ```language-json { "project_id": 42, "payment":{ "id": "567890", "type": "purchase", "status": "success", "date": "2019-05-14T12:52:45+0000", "method": "card", "sum":{ "amount": 400, "currency": "USD" }, "description": "" }, "account":{ "number": "431422******0056", "token": "d927d3f006008edf5c07661", "type": "visa", "card_holder": "JUDY DOE", "expiry_month": "08", "expiry_year": "2025" }, "customer":{ "id": "customer_1" }, "recurring":{ "id": 1001648059, // ID of the record about a range of withdrawals "currency": "USD", "valid_thru": "2019-05-20T00:00:00+0000" }, "scheme\_id":"MCS38A0790706", "operation":{ "id": 22136002040, "type": "sale", "status": "success", "date": "2019-05-14T12:52:45+0000", "created_date": "2019-05-14T12:52:42+0000", "request_id": "8c77279053d011-1160421d51e11f87d2c", "sum_initial":{ "amount": 400, "currency": "USD" }, "sum_converted":{ "amount": 400, "currency": "USD" }, "provider":{ "id": 414, "payment_id": "00200011764", "date": "2019-05-14T12:52:55+0000", "auth_code": "231567", "endpoint_id": 414 }, "code": "0", "message": "Success", "eci": "07" }, "signature": "v7KNMpZ1ZZ5D/aZAebR+CqGrUwSm..." } ``` **Parent topic:**[Basic actions](en_pp_basic_actions.md) --- # Performing payouts {#en_pp_payout} An article about processing payouts via Payment Page. ## Overview {#section_l4s_bhz_dbc .section} The Ecommpay payment platform supports the capability to issue payouts to card accounts with the use of Payment Page. Each payout is at first registered via the Gate API and then the payment form is opened in the Payout operation mode.Along with that, payouts via Payment Page can originate both from the merchant and from a physical person, while their processing can involve Mastercard MoneySend and Visa Direct services. **Note:** Performing payouts is available only for the 5th generation Payment Page. To register a payout, send a corresponding request to the platform via the Gate API and receive a callback about the registration result.If the payout has been registered, the callback contains a special identifier \(`uuid`\) that must be specified in the request for opening Payment Page. Keep in mind that this identifier is valid for 30 minutes and the time that remains for confirming the payout is displayed on the payment form pages. In case if the customer does not confirm the payout until the allocated time expires, a corresponding notification is displayed to this customer and, for the payout to be processed, it has to be re-registeredwith a new payment identifier \(`payment_id`\) specified. A payout via Payment Page is made upon the customer's confirmation with the use of a confirmation code. Such codes are sent from the payment platform to the customer's email address provided during the payout registration. ![](images/ecommpay/en_pp_payout_code.svg "Example of an email with a confirmation code") When the customer requests a payout with the use of Payment Page, they select a payment instrument, specify the instrument credentials, then enter the confirmation code, and receive a notification about the result. The payment instrument credentials can be specified in one of the following ways: - *On the payment form, by completing the fields.*In this case, the customer completes all required fields on the payment form. - *On the payment form, by completing the fields or selecting saved payment information.*In this case, the customer can either select one of the saved payment instruments or enter new payment information. The new payment instrument can also be saved for subsequent payment processing. - *Outside the payment form, by selecting previously saved payment information.*In this case, the customer selects a specific card in the web service, the token associated with this card is specified in the request for opening Payment Page, and once the payment form is opened, it already contains all required payment information. Payout processing can be finalised with the generation of payment card tokens. It is applicable when card details have not been saved before, and this capability has been set up for the merchant's project in use \([details](en_pp_token.md)\). ## Customer payout scenario {#section_rxt_bhz_dbc .section} Suppose that the customer Prostetnik Jeltz has won the third place in the Millstone Jennings Poetry competition with the prize of 70 EUR.To receive the funds, the customer specifies their payment instrument details, first name, and last name, then confirms the payout and waits for its result. ![](images/ecommpay/en_pp_payout_1.svg "Specifying payment data") ![](images/ecommpay/en_pp_payout_2.svg "Entering a confirmation code") ## Restrictions {#section_jt5_bhz_dbc .section} The following restrictions apply to processing payouts via Payment Page: - You have to make sure that this capability has been added and set up for the project in use. When the payment form is opened in the Payout operation mode within the project without the integrated payouts functionality, a callback with the `317` error code is sent from the payment platform to the web service \([details](en_platform_payment_info_codes.md)\). - To send requests for payouts registration, use the IP addresses that you provided to the Ecommpay technical support specialists who subsequently added them to the whitelist. If a request is sent from an IP address that is not whitelisted, a response with the `403` error code is sent from the payment platform to the web service \([details](en_gate_interaction_organisation.md#)\). - The limits set for the payout recipient's payment card must be complied with. These limits include the number of payouts, their amount in total, and the amount of a one-time transfer of funds. If any of these limits is exceeded, the payout is declined, the customer is shown a page with the message that the payment has been declined, and a callback with the relevant error code is sent to the web service. - The merchant's account balance must contain enough funds for issuing a payout. If there are insufficient funds, the payout is declined, the customer is shown a page with the message that the payment has been declined, and a callback with the relevant error code is sent to the web service. Balance information can be monitored via Dashboard \([details](en_dbl_balances.md#)\) and retrieved via the Data API \([details](en_dbl_api_protocol.md)\). If you have any questions, contact your Ecommpay account manager. - You must comply with requirements imposed by global card networks and programs within which payouts are issued as well as requirements and rules that are specific to particular regions, payment systems, and providers. Depending on the program, for example, there are different requirements as to what information about the payout sender or recipient should be provided in the requests for opening Payment Page. **Note:** These requirements may have to do with such cases as follows: - For payouts performed as part of the Mastercard MoneySend service when the payout sender is a physical person, it is required that the first name and the last name of the payout recipient as well as the first name and the last name, the payment instrument identifier and the address of the payout sender are specified—if this data is not specified, the payout is declined. - For payouts performed as part of the Visa Direct Money Transfer program, in case of a payout to a card issued in Canada, it is required that the payout recipient's address is specified—if this data is not specified, an additional page with fields to fill in with the details is displayed to the customer. For more in-depth understanding of performing payouts depending on different conditions, refer to your account manager. - When opening the payment form, the capability of limiting the time for working with it must not be used \([details](en_pp_time_limit.md)\). The time of working with the payment form is limited by default and equals the validity period of the `uuid` identifier. If the request for opening the payment form contains the date and time limiting the work with the form, the customer is shown the payment form page with the error message. ## Setup {#section_emv_bhz_dbc .section} To have the capability of processing payouts with the use of Payment Page set up, merchants should complete the following steps: 1. Discuss with the Ecommpay account manager and agree on the capability setup steps, the need for testing the capability, and the application of restrictions in each particular case. 2. If it was agreed that testing is required, wait to be notified by the Ecommpay specialists when the functionality is ready, then test the payment form workflow with the new capability. After that, inform the account manager that you are ready to launch the functionality in your production environment. 3. Receive a notification about the completion of the capability setup from the Ecommpay specialists. ## Workflow {#section_w2w_bhz_dbc .section} To perform a payout via Payment Page, the web service is required to do the following: 1. Generate the request for registering a payout and send it to the payment platform. 2. Receive a callback with information about payout registration from the platform. 3. Generate and send a request for opening Payment Page in the Payout operation mode. 4. Receive a callback with information about the payment processing result from the payment platform. It may be needed to carry out an additional procedure of the *payment information submission* when processing payouts.The customer will be shown a message and additional fields to be completed on the payment form. This procedure is performed without the merchant's web service involved, but it does require the participation of the customer. ![UML-scheme](images/ecommpay/en_payout_pp_uml.svg) 1. A customer initiates a payout in the web service. 2. The web service sends the request for payout registration by using Gate to the specified Ecommpay URL. 3. The payment platform receives the request. 4. The payment platform validates the required parameters and signature in the request. 5. The payment platform sends the response to the web service with information about the receipt of the request and its validity\([details](en_gate_interaction_organisation.md#)\). 6. The request is processed on the payment platform side. 7. The payment platform sends the callback with the payout identifier\(`uuid`\) to the web service. 8. The web service sends the request for opening Payment Page to the specified Ecommpay URL. 9. The request for opening Payment Page is sent to the payment platform. 10. The payment platform receives the requestand validates the required parameters and signature. 11. Payment Page is generatedbased on the project and request parameters. 12. Payment Pagewith an indicator that shows the time remaining for working with the form is displayed to the customer. 13. The customer performs required actions and confirms the payout. 14. The payment platform receives the request for processing the payout. 15. The payment platform processes the request and sends it to the payment environment. 16. The request is processed on the payment environment side. 17. The payment environment sends the payout result information to the payment platform. 18. The payment platform sends a callback with the payout result information to the web service. 19. The payment platform sends the information about the payout result to Payment Page. 20. The payout result information is displayed to the customer on Payment Page. ## Format of request for payout registration {#section_bxw_bhz_dbc .section} There are several things you should consider when sending a request for payout registration: 1. In every case of payout registration, send a separate POST request to the endpoint. 2. Each request must include the following objects and parameters: - Object `general`—general identification information of the request: - `project_id`—project identifierobtained from Ecommpay during integration - `payment_id`—payment identifierunique within the project - `signature`—request signaturegenerated after all required parameters are specified \(details—in the [Signature generation and verification](en_platform_signature.md#)\) - Object `payment`—payment information: - `amount`—payment amount in the smallest currency unit - `currency`—payment currency codein the ISO-4217 alpha-3 format - Object `customer`—customer information: - `id`—customer's identifierunique within the project - `email`—customer's email address - `phone`—customer's phone number - `ip_address`—customer's IP addressrelevant for the payout being registered Thus, a correct request for payout registration must contain the project identifier, basic payment information \(identifier, amount, and currency code\), customer information and signature. ```language-json "general": { "project_id": 91348, "payment_id": "cosmoshop_payout_1323", "signature": "iehD3ZeW3CM7aGfmdgfjdgneHbCmronMpXom1b/ot1HvOGMV+CT8LA==" }, "customer": { "id": "16061314", "email": "p.jeltz@mail.com", "phone": "44991234567", "ip_address": "93.47.230.225" }, "payment": { "amount": 7000, "currency": "EUR" } } ``` ## Format of callback with the payout registration result {#section_a1k_dhz_dbc .section} During the processing of a payout with the use of Payment Page, on the web service side it is required to receive an intermediate callback with information about the payout registration result from the payment platform and use the identifier submitted in the `uuid` parameter. The format of such callbacks is standard \([details](en_platform_callbacks.md#)\). The following is an example of a callback indicating that a payout has been registered in the `91348` project for the `16061314` customer. ```language-json { "general": { "project_id": "91348", "payment_id": "cosmoshop_payout_1323", "signature": "V2mxcUcGUcCtAE51lgesBefZgfG9NHpQEbfdI2X1Q==" }, "request_id": "50715", "payment": { "id": "cosmoshop_payout_1323", "type": "payout", "status": "awaiting_payout_completion", }, "operation": { "id": "500359719", "type": "payout", "status": "awaiting_payout_completion" }, "customer": { "id": "16061314" }, "sum_request": { "amount": "7000", "currency": "EUR" }, "transaction": { "type": "payout" }, "uuid": "Lm3V9lmykig2d51Z/2Yrnue9+o5GTkVvY/sRDLKAnSS+AagnGCJ1nsPg==", "uuid_expired_at": "2024-04-24T13:50:37+0000" } ``` ## Format of request for opening the payment form {#section_umk_dhz_dbc .section} The format of request for opening Payment Page to process card payouts is the same as the one described in the [Interaction concepts](en_pp_interaction_organisation.md#) section. When generating such requests, you should consider the following: 1. The following parameters must be specified in the request: - `mode`—the indicator of the Payment Page operation mode. The value must be `payout`. - `project_id`—project identifier obtained from Ecommpay during integration - `payment_id`—payment identifier specified in the request for payout registration and unique within the project **Warning:** Payment identifiers \(`payment_id`\) specified in the request for payout registration and the request for opening the payment form must match. If the identifiers do not match, the payment form will not open and the customer will be shown an error message. - `uuid`—payout identifier received in a callback with information about the payout registration result - `customer_id`—customer's identifier specified in the request for payout registration and unique within the project - `customer_email`—customer's email address specified in the request for payout registration - `payment_amount`—payment amount specified in the request for payout registration, in the smallest currency unit - `payment_currency`—payment currency code specified in the request for payout registration, in the ISO-4217 alpha-3 format - `signature`— the request signature generated after all required parameters have been specified \(for more information, see [Signature generation and verification](en_platform_signature.md#)\). 2. To use a token of the payment card that the customer has selected in the web service, specify this token as a value of the `account_token` parameter. 3. To provide information about the payout sender, specify the following parameters in the request: - `sender_wallet_id`—sender's wallet number - `sender_first_name`—sender's first name - `sender_last_name`—sender's last name - `sender_country`—sender's country code in ISO 3166-1 alpha-2 - `sender_state`—the sender's country subdivision code \(state, province, region, or territory\). The value of this parameter is the second element of a code for a subdivision \(in ISO 3166-2\), without the two-letter country code and the hyphen-minus used as a separator. For example, `ON` for the province of Ontario in Canada \(with `CA-ON` being the complete code for the subdivision\) - `sender_city`—sender's city - `sender_address`—sender's street address - `sender_zip`—sender’s postal code 4. To provide information about the payout recipient, specify the following parameters in the request: - `recipient_first_name`—recipient's first name - `recipient_last_name`—recipient's last name - `recipient_country`—recipient's country code in ISO 3166-1 alpha-2 - `recipient_state`—the recipient’s country subdivision code \(state, province, region, or territory\). The value of this parameter is the second element of a code for a subdivision \(in ISO 3166-2\), without the two-letter country code and the hyphen-minus used as a separator. For example, `ON` for the province of Ontario in Canada \(with `CA-ON` being the complete code for the subdivision\) - `recipient_city`—recipient's city - `recipient_address`—recipient's street address In the case of payout to a Visa card issued in Canada, the request must contain the payout recipient's address data: the country code \(`recipient_country`\), the city \(`recipient_city`\), the street address \(`recipient_address`\) and, if the recipient's country code is [CA](references/en/countries/CA.md) or [US](references/en/countries/US.md), the code of the state, province, or territory \(`recipient_state`\). 5. To display Payment Page in a required language, you need to additionally specify the `language_code` parameter. If this parameter is not specified, the payment form is displayed in the language selected automatically \(by the browser settings or by default—[details](en_PP_WigetLanguages.md)\). 6. To add a description of the payment, you need to specify the `payment_description` parameter. The value of this parameter is shown to the customer on the page with information about the payout result and is available to the merchant's employees in Dashboard and in callbacks. 7. Additionally, any other parameters supported by Payment Page in the Payout operation mode can be used in requests. The full list of parameters for opening Payment Page is provided in the article [Payment Page API specification](en_PP_Parameters.md). Thus, a correct request for payout must include project, payment, and customer identifiers, the identifier from the callback with information about the payout registration, the email address of the customer, signature, payment currency and amount. Along with that, other parameters can be used in requests. ```language-json { "project_id": "91348", "payment_id": "cosmoshop_payout_1323", "payment_currency": "EUR", "payment_amount": "7000", "customer_id": "16061314", "customer_email": "p.jeltz@mail.com", "mode": "payout", "uuid": "Lm3V9lmykig2d51Z/2Yrnue9+o5...", "signature": "xxPURAKgVtgW4PY7QlbIdS5u7gdoXkhXvZB..." // when processing payment using preselected card: "account_token":"959c664ad6045679d71d89caff6c242a0..." } ``` ## Format of callback of payout processing result {#section_d21_b4z_dbc .section} The format of callbacks used to communicate the results of processing card payouts is the same as the one described in the [Handling callbacks](en_platform_callbacks.md#) section. **Parent topic:**[Basic actions](en_pp_basic_actions.md) --- # Payment instrument verification {#en_pp_account_verification} An article about verifying a payment instrument via Payment Page by debiting a zero amount or placing a hold on funds. **Note:** This article covers payment instrument verification via Payment Page and describes requests and callbacks that are used in case of card payments. In addition, use the following materials to gain a fuller understanding of payment instrument verification: - [Payment instrument verification](en_platform_account_verification_model.md)—an article in the section [Payment processing](en_platform_payment_model.md) that provides a general description of performing payment instrument verification in the Ecommpay payment platform and covers information about statuses that can be used in the process. - articles of the [Payment methods](en_pm_about.md) section containing a description of payment instrument verification via Payment Page with the focus on the specific features of the payment method used and information about relevant requests and callbacks. To find out whether you can use payment instrument verification, refer to your Ecommpay account manager. ## General information {#section_w3f_5qf_dmb .section} *Payment instrument verification* is a payment type in which the customer card or account is validated by either transferring a dummy \(zero\) amount from customer to merchant or by authorizing a specific amount \(non-zero\) on the customer cardor account and then voiding the transfer or the authorization. Authorization amount can be changed on merchant's request. The authorized amount can be held up to 45 days. This option may be convenient for validating a payment instrument without withdrawing funds instantly, for example, before performing a payout orwhen registering in a service that offers a free trial period followed by subsequent withdrawals of funds \(for more information about such cases, see the article [COF purchase registration](en_pp_recurring.md)\). For performing payment instrument verification on Payment Page, the Card Verify operation mode of the payment form is used. During the work with this mode, it is possible to specify card details the customers submitted via the means of communication\(Mail Order / Telephone Order; MO/TO\) and save the provided card details in the platform. In terms of performing payment instrument verification using Payment Page, the basic steps that the customer performs may be specifying payment information, saving the payment information for subsequent payments processing and waiting for notification about the result. ![](images/ecommpay/en_pp_account_verification.svg) ## Workflow {#section_zvb_r3l_dmb .section} Payment instrument verification by using Payment Page requires the merchant web service to do the following: 1. Create and send a request for opening Payment Page to the payment platform. 2. Receive callback with the result of the request processing from the payment platform. Payment instrument verification may involve auxiliary procedures: - *3‑D Secure authentication*, in terms of which the customer is transferred to the service of the issuer where the customer needs to complete authentication using the code received by SMS or performing other required steps, or loading page is displayed \(while issuer confirms authentication with no customer effort required\). - *Submission of additional payment information*, in terms of which notification and additional fields to be completed are displayed on the payment form. The fields should be completed on the same page of the payment form. These procedures do not require any additional effort on the merchant's web service side, but usually require customer effort. The following sections cover information about request and callback formats to use when performing payment cards verification. ## Request format {#section_acq_2pl_dmb .section} The format of the request for opening Payment Page to perform payment instrument verification is the same as the request format described in the [Request format](en_pp_interaction_organisation.md#) section. When creating request, you should consider the following: 1. The following required parameters must be used: - `mode`—the indicator of the Payment Page operation mode. The value must be `card_verify`. - `project_id`—the project ID obtained from Ecommpay. - `payment_id`—the payment ID unique within the project. - `payment_amount`—payment amount in minor currency units, the `0` value must be specified. - `payment_currency`—payment currency code in the ISO-4217 alpha-3 format. - `signature`—the signature that is created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#). 2. In order to register a COF purchase, you need to additionally specify the `recurring` parameter with information about this COF purchase \(for more information, see [COF purchase registration](en_pp_recurring.md)\). 3. To save payment instrument details, you need to additionally specify the `customer_id` parameter and the customer ID in merchant's web service as its value. 4. To perform verification on the instrument token, specify the `account_token` parameter—the token received from Ecommpay. 5. To display Payment Page in a required language, you need to additionally specify the `language_code` parameter. If this parameter is not specified, the payment form is displayed in the language selected automatically \(by the browser language or by default—[learn more](en_PP_WigetLanguages.md)\). 6. To add description of the payment, you need to specify the `payment_description` parameter. The value of this parameter is displayed to the customer on the page with information about the result and to the merchant in Dashboard and in a callback with information about the payment result. 7. To specify card details submitted by customers via the means of communication, you must use the `moto_type` parameter with the value `1`, for mail communication \(Mail Order\), or `2`, for telephone communication \(Telephone Order\). 8. If needed, you can also add any other additional parameters supported by Payment Page in the Card Verify operation mode. The full list of parameters for opening Payment Page is provided in the [Payment Page API specification](en_PP_Parameters.md) section. Thus, a correct request for payment instrument verification must include Payment Page operation mode indicator, project and payment IDs, signature, payment currency and amount. In order to save the payment information, you also need to specify `customer_id`, and in order to register COF purchase, you also need to specify a string which contains set of corresponding parameters. ```language-json { "mode": "card_verify", "project_id": 874, "payment_id": "15538406111", "payment_currency": "EUR", "payment_amount": 0, "signature": "TSzdE5rJpfXriFf82MxF...", // saving payment information: "customer_id": "customer_10", // verification by card token: "account_token": "42ab631449a78914502803aed8a0e5a728d558035d29a56f4dcc136c6bfc3021", // registering COF purchase: "recurring": { "register": "true", "type": "R", ... } } ``` ```language-json https://paymentpage.ecommpay.com/payment?payment_currency=EUR&language_code=en&mode=card_verify&project_id=874&payment_amount=0&payment_id=15538406111&css_modal_wrap=standart&signature=Z0QkrvLe%2Fl6Vdyxb4%2F0zwcPT8E... ``` ## Callback format {#section_l5r_5mm_dmb .section} To notify the merchant about the result of payment instrument verification, the standard callback format is used. For more information, see [Handling callbacks](en_platform_callbacks.md#). The following is an example of a callback with information about successful verification of the card with the card number `431422******0056` of the customer `customer_10` and successful registration of the card for subsequent COF purchases. ```language-json { "project_id": 874, "payment": { "id": "15538406111", "type": "account_verification", "status": "success", "date": "2020-06-10T13:45:59+0000", "method": "card", "sum":{ "amount": 0, "currency": "EUR" }, "description": "Add the card" }, "account":{ "number": "431422******0056 ", "token": "844f84f3bdfaf2ddf006c96ffaddc09394c5d0e158f", "type": "visa", "card_holder": "JOHN SMITH", "id": 8861226, "expiry_month": "09", "expiry_year": "2025" }, "customer":{ "id":"customer_10" }, "recurring":{ "register": "true", "type": "R" }, "operation":{ "id": 42209000002431, "type": "account verification", "status": "success", "date": "2020-06-10T13:45:59+0000", "created_date": "2020-06-10T13:45:57+0000", "request_id": "5cb898347e62b2c1-52dac6c8c", "sum_initial":{ "amount": 0, "currency": "EUR" }, "sum_converted":{ "amount": 0, "currency": "EUR" }, "provider":{ "id": 120, "payment_id": "306449667", "date": "2020-06-10T13:45:59+0000", "auth_code": "188591", "endpoint_id": 120 }, "code": "0", "message": "Success" }, "signature": "P9g0U+eF2QWs2A..." } ``` The following is an example of a callback with information about declined payment instrument verification with no decline reason specified. ```language-json { "project_id": 874, "payment":{ "id": "15538406111", "type": "account_verification", "status": "decline", "date": "2020-06-16T06:06:53+0000", "method": "card", "sum":{ "amount": 0, "currency": "EUR" }, "description": "Add the card" }, "account":{ "number": "431422******0056 ", "type": "visa", "card_holder": "JOHN SMITH", "expiry_month": "09", "expiry_year": "2025" }, "customer":{ "id": "customer_10" }, "operation":{ "id": 40975000002863, "type": "account verification", "status": "decline", "date": "2020-06-16T06:06:53+0000", "created_date": "2020-06-16T06:06:47+0000", "request_id": "9120271eb02-83e0e70fc0a0a3c1b4d", "sum_initial":{ "amount": 0, "currency": "EUR" }, "sum_converted":{ "amount": 0, "currency": "EUR" }, "provider":{ "id": 120, "payment_id": "308822001", "date": "2020-06-16T06:06:49+0000", "auth_code": "", "endpoint_id": 120 }, "code": "10100", "message": "Declined by external provider" }, "signature": "P9g0U+eaZ9EeNiWiaQWs2A..." } ``` **Parent topic:**[Basic actions](en_pp_basic_actions.md) --- # Tokenization {#en_pp_token} An article about opening the payment form for registering payment data and generating a token for this data. ## General information {#section_stq_mw3_2mb .section} Payment Page allows creating tokens. Tokens are stored on the merchant web service side and can be used for purchase processing by using Payment Pageand Gate and for payout processing by using Gate. *Token* is a unique, random sequence of 64 characters associated in terms of the payment platform with a specific payment card. Token is created based on customer payment information, such as payment card number, name and surname of cardholder and card expiration date. Tokenization can be performed in the following cases: - Payment Page is opened in the Card Tokenize mode. - purchase processing with saving payment information in the Purchase mode completes successfully. - the first purchase or payoutprocessing using payment card completes successfully—if this option is available to merchant project. In order to configure automatic tokenization using this option, contact Ecommpay technical support \([support@ecommpay.com](mailto:support@ecommpay.com)\). In each case for a particular payment card one token is created with the expiration date equal to the expiration date of the payment card, and the status of the token is `active`. Once the token expires, the status is set to `expiry`. If the token is deleted on request from the web service, the status is set to `revoke`. In both cases \(`expiry` and `revoke`\) payment processing using this token is unavailable. To delete token or obtain payment information related to the token, you need to use Gate.For more information, see [Using tokens](en_Gate_Token.md). When tokenization is used via Payment Page, basic steps that the customer performs include specifying card details and waiting for notification about the result.Following the successful generation of the payment card token, the details of this card are shown on the saved payment instruments list of the payment method selection page. ![](images/ecommpay/en_pp_token.svg) This section covers information about tokenization performed by using Payment Page in the Card Tokenize mode. For information about tokenization performed during purchase processing, see [Purchase processing](en_pp_purchase.md). ## Workflow {#section_hcr_1g4_2mb .section} In terms of performing tokenization by using Payment Page, the merchant web service is required to do the following: 1. Create and send a request for opening Payment Page to the payment platform. 2. Receive the callback with the result of the request processing from the payment platform. ## Request format {#section_rgv_yr2_plb .section} The format of the request for opening Payment Page to perform tokenization is the same as the request format described in the [Request format](en_pp_interaction_organisation.md#) section. When creating request, you should consider the following: 1. The request must contain the following required parameters: - `mode`—the indicator of the Payment Page operation mode. The value must be `card_tokenize`. - `project_id`—the project ID obtained from Ecommpay. - `customer_id`—the customer ID unique within the project. - `signature`—the signature created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#). 2. To display Payment Page in a required language, you need to additionally specify in the request the `language_code`parameter and the language code in accordance with ISO 639-1 alpha-2 as its value. If this parameter is not specified, the payment form is displayed in the language selected automatically \(by the browser language or by default—[learn more](en_PP_WigetLanguages.md)\). 3. If needed, you can also add any other additional parameters supported by Payment Page in the Card Tokenize mode. The full list of parameters for opening Payment Page is provided in the [Payment Page API specification](en_PP_Parameters.md) section. Thus, a correct payment request must include identifier of the Payment Page operation mode, project and customer IDs and signature. ```language-json { "mode": "card_tokenize", "project_id": 112, "customer_id": "cust_123", "signature": "TSzdE5rJZaA9VyJtnfRI362oGpfXriFf82MxF..." } ``` ```language-json https://paymentpage.ecommpay.com/payment?signature=A%2Fqqxsl59tRrtACreixy8sieSfxR%2BC...&mode=card_tokenize&project_id=112&customer_id=cust_123®ion_code=EU&language_code=en ``` ## Callback format {#section_x3c_5zd_plb .section} The format of the callback to notify the merchant about token creation is the same as the format described in the [Handling callbacks](en_platform_callbacks.md#) section. The following is an example of a token \(`token`\) created for the customer `cust_123` in terms of the project `112`. Date and time of token creation \(`token_created_at`\) as well as the current status of the token \(`token_status`\) are also specified. ```language-json { "general": { "project_id": 112, "customer_id": "cust_123", "signature": "mTHcy5wvpOYkl9S5eLJZ..." }, "request": { "id": "3c7f53fdbb5b8c96f9707457d75f", "action": "tokenize", "status": "success" }, "token":"2f0e75befacca30623354f9ffb0f44a80bee52982c39727b85039ef6f64309a1", "token_created_at":"2020-03-28 13:30:57", "token_status":"active" } ``` **Parent topic:**[Basic actions](en_pp_basic_actions.md) --- # Auxiliary procedures and additional capabilities {#en_PP_Additional .concept} Articles about auxiliary procedures and additional capabilities of Payment Page for boosting payment acceptance rates, customer convenience, and the quality of the provided services. This subsection provides the information about various *procedures* and *capabilities*. While the procedures can be run automatically during the Payment Page operation for processing separate payments and affect user scenarios, the capabilities can be implemented upon the merchant request for improving the provided service. ## Boosting payment acceptance rates {#section_pv1_qq1_dtb .section} The procedures and capabilities that can help to ensure high acceptance rates: - [3‑D Secure authentication](en_pp_3ds.md#)—about the procedure of performing customer authentication for processing card payments. - [Checking with Address Verification Service](en_PP_avs.md)—about the procedure of specifying customers' postal codes and addresses for processing payments with the use of the cards American Express,Mastercard, and Visa. - [Submission of additional payment information](en_pp_clarification.md)—about the procedure of specifying additional data that can be requested by payment systems in certain cases. - [Payment retries](en_PP_Try_Again.md)—about the capability of providing the customers with additional payment attempts \(in case of other attempts failure\), including the capability of changing the payment method. - [Cascade payment processing](en_pp_cascading.md#)—about the capability of making additional payment processing attempts \(when relevant\), without changing the payment method. - [Collecting customer data](en_PP_Gathering_customer_data.md)—about the capability of obtaining and providing customer additional information. This can help to avoid the implementation of some auxiliary procedures. ## Improving customer experience {#section_zdq_tjf_dtb .section} The capabilities that can be used for adjusting payment scenarios to different situations: - [Interface language support](en_PP_WigetLanguages.md)—about the capabilities of specifying the language used when the payment form is displayed. - [Preselecting payment methods](en_PP__PreselectingPS.md)—about the capability of specifying a certain payment method when opening the payment form. - [Managing payment methods availability](en_pp_methods_availability.md#)—about the capability of displaying to the customers not all but only the relevant payment methods from the ones available for the project. - [Arranging payment methods on the page](en_pp_methods_order.md)—about the capability of arranging payment methods to be presented to the customer in the optimal order. - [Saving customer payment data](en_PP_saved_data.md)—about the capabilities of saving and using the customer payment data when working with the payment form. - [Payments by using tokens](en_PP_Payment_by_token.md#)—about the capability of using payment data tokens for shortening the customer payment scenarios. - [Currency conversion](en_pp_currency_conversion.md)—about the capability of processing payments in different currencies with currency conversion. - [Currency choice in Payment Page](en_pp_currency_choice.md)—about the capability of enabling customers to choose payment currency that fits their needs. - [Supporting sustainable payments](en_pp_ekko_earth.md)—about the capability of making financial contributions to environmental projects via the specialised partner service of the [ekko](https://ekko.earth/) platform. ## Supporting specific scenarios of working with the form {#section_w5j_ftf_dtb .section} The capabilities of adapting the payment form to different industries, types of business, and particular cases: - [Debt repayment](en_PP_debt_repayments.md)—about the capability of using the payment form for accepting loan and credit repayments. - [Limiting time for working with payment form](en_pp_time_limit.md)—about the capability of setting the time limit for making a purchase. - [Specifying extended purchase data for subsequent merchant use](en_pp_additional_data.md#)—about the capability of passing relevant purchase information to be used by merchants at their discretion. ## Monitoring payment form usage {#section_src_3zf_dtb .section} The capabilities of obtaining and processing the information about various interface events related to the payment form and customer actions in this form—[Handling events in Payment Page](en_pp_ui_monitoring.md#). ## Informing customers {#section_dyv_q1g_dtb .section} The information about the capabilities that can be used for informing customers: - [Using dynamic merchant descriptor](en_pp_descriptor.md)—about the capability of providing customers with information about merchants via issuer services. - [Sending receipts and notifications to customer](en_PP_receipt_data.md)—about the capability of informing customers about payment processing and related events via email notifications. - **[3‑D Secure authentication](en_pp_3ds.md#)** An article about the procedure of authenticating customers with the use of the 3‑D Secure protocol for processing card payments via Payment Page. - **[Checking with Address Verification Service](en_PP_avs.md)** An article about the procedure of verifying customers' postal codes and addresses for processing American Express, Mastercard, and Visa payments via Payment Page. - **[Submission of additional payment information](en_pp_clarification.md)** An article about the procedure of specifying additional data that can be requested by payment systems during payment processing via Payment Page. - **[Payment retries](en_PP_Try_Again.md)** An article about the capability of providing customers with additional payment attempts via Payment Page if the previous attempt to pay has failed, with the option to select the payment method. - **[Cascade payment processing](en_pp_cascading.md#)** An article about the capability of making additional attempts to process a payment via Payment Page if the previous attempt has failed, without changing the payment method initially selected. - **[Collecting customer data](en_PP_Gathering_customer_data.md)** An article about the capability of obtaining and using additional customer information during payment processing via Payment Page to minimise the need for auxiliary procedures. - **[Interface language support](en_PP_WigetLanguages.md)** An article about the capabilities of specifying the language used when the payment form is displayed. - **[Preselecting payment methods](en_PP__PreselectingPS.md)** An article about the capability of preselecting a specific payment method when invoking the payment form. - **[Managing payment methods availability](en_pp_methods_availability.md#)** An article about the capability of configuring payment method selections relevant to each payment form invocation. - **[Arranging payment methods on the page](en_pp_methods_order.md)** An article about the capability of arranging payment methods on the form to be presented to the customer in the optimal order. - **[Saving customer payment data](en_PP_saved_data.md)** An article about the capabilities of saving and using the customer payment data when working with the payment form. - **[Payments by using tokens](en_PP_Payment_by_token.md)** An article about the capability of using payment data tokens to reduce the number of steps in customer payment scenarios. - **[Currency conversion](en_pp_currency_conversion.md)** An article about the capability of processing payments via Payment Page in different currencies with currency conversion. - **[Currency choice in Payment Page](en_pp_currency_choice.md)** An article about the capability of letting customers choose payment currency that fits their needs in the payment form. - **[Supporting sustainable payments](en_pp_ekko_earth.md)** An article about the capability of adding the option to payment form workflows that allows contributing to environmental projects via the ekko partner service. - **[Debt repayment](en_PP_debt_repayments.md)** An article about the capability of using the payment form to accept loan repayments. - **[Limiting time for working with payment form](en_pp_time_limit.md)** An article about the capability of setting the time limit for making a purchase within a single payment form invocation. - **[Specifying extended purchase data for subsequent merchant use](en_pp_additional_data.md#)** An article about the capability of capturing relevant purchase information via Payment Page for internal merchant use. - **[Handling events in Payment Page](en_pp_ui_monitoring.md#)** An article about the capabilities of obtaining and processing the information about various interface events related to the payment form and customer actions in this form. - **[Using dynamic merchant descriptor](en_pp_descriptor.md)** An article about the capability of providing customers with information about merchants via issuer services. - **[Sending receipts and notifications to customer](en_PP_receipt_data.md)** An article about the capability of informing customers about payment processing and related events via email notifications. **Parent topic:**[Payment Page](en_PP_about.md) --- # Checking with Address Verification Service {#en_PP_avs .concept} An article about the procedure of verifying customers' postal codes and addresses for processing American Express, Mastercard, and Visa payments via Payment Page. ## General information {#section_ofb_dcx_ydb .section} **Address Verification Service** \(AVS\) is a service that allows you to check whether a customer who makes a payment by a bank card is the actual cardholder. The AVS check is performed by matching the address specified by a customer while performing a payment with the cardholder address according to the bank card Issuer. AVS verification is mandatory for payments with Visa and Mastercard cards performed in the UK, and optional in the USA, Australia, Canada and New Zealand. For American Express, AVS verification is mandatory in the USA and Canada and optional in other countries.Therefore, it may be required additional mandatory parameters in the request for payment: the postal code `avs_post_code` and the address `avs_street_address` of a customer, for more information, see [Submission of additional payment information](en_pp_clarification.md). If the data does not passed, not pass validation or empty, you receive the appropriate decline code and message. The result of the AVS check is sent in the callback parameter `avs_result`. **Note:** The requirement to provide AVS parameters persists even if the payment is made by a token or a saved bank card. ## Results of checking with AVS {#section_gq3_n12_pfb .section} Possible codes with additional information and descriptions can be found below. |Code|Additional information|Description| |----|----------------------|-----------| |W, Z|Partial match|Post code matches, but street address does not| |A|Partial match|Street address matches, but post code does not| |X, Y|Exact match|Address and post code match| |N|No match|Street address and post code do not match| |S, U|Address information unavailable.|Address information is unavailable for this account or an issuing bank does not support the AVS| |R|System unavailable|System is unavailable at the moment, retry| |VISA|A, N, R, U, Y, Z| |MasterCard|A, N, R, S, U, W, X, Y, Z| |American Express|A, N, R, S, U, Y, Z| **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Submission of additional payment information {#en_pp_clarification .concept} An article about the procedure of specifying additional data that can be requested by payment systems during payment processing via Payment Page. ## General information {#section_vgn_22h_nmb .section} Mandatory parameters specified in the request for opening Payment Page usually provide enough information for payment processing. However, a payment systemor a payment provider may require some additional data that otherwise is not required, this may be due to regional or country-specific requirements, additional fraud testing procedures or other conditions. Payment Page allows you handling such cases as it supports *submission of additional payment information*. In terms of this procedure, the customer is notified about the need to submit additional data, the required data is collected and the payment is processed considering the provided data. Submission of additional payment information does not require extra effort of the merchant, as the procedure is performed through interaction between the customer and the payment platform. Nevertheless, in order to avoid the need of submitting additional data, you can specify in the request for opening Payment Page data that may be required by payment systemsor payment providers for processing payments, including optional parameters. The requested data generally concerns the customer and their payment instrument, and for payments by using alternative payment methods it is the data provided in any optional parameters supported by Payment Page for initial request for payment processing. The information that the customer may be requested to provide may include the following: - `customer_first_name`—first name - `customer_last_name`—last name - `customer_middle_name`—middle name - `customer_day_of_birth`—birth date - `customer_email`—email address - `customer_address`—the name of the street and the house number \(including any additional parts of the address such as building indicators and apartment numbers\) in the customer's address - `customer_city`—city of residence - `customer_country`—code of the country - `customer_street`—street of residence - `customer_zip`—postal code **Note:** The final set of the requested data depends on the requirements of a particular provider orpayment system and may vary.To precise the set of the data that may be requested depending on the payment method, you may contact your Ecommpay key account manager. Payment processing continues only after the customer specifies requested data and confirm the purchase. The following sections provide information about steps that the customer performs when submitting additional payment information. ## Usage scenario {#section_hbw_wjh_nmb .section} The basic usage scenario of submitting additional payment information can be described as follows: 1. On the merchant web service side, the customer confirms the purchase of the order and is redirected to the payment form. If the option of time limit for using the payment form is enabled, the remaining time is also displayed on Payment Page. 2. The customer enters the payment details. 3. As the need for additional payment information is identified, a notification and additional fields for entering the data are displayed on Payment Page. The customer enters additional data, confirms the purchase and receives the result information. ![](images/ecommpay/en_pp_clarification_1.svg "1 — Opening payment form") ![](images/ecommpay/en_pp_clarification_2.svg "2 — Entering payment details") ![](images/ecommpay/en_pp_clarification_3.svg "3 — Entering additional data") ## The workflow {#section_gd4_gkh_nmb .section} The following diagram illustrated the procedure of submitting additional payment information. ![](images/eng_pp_clarification_uml.svg) 1. When the need for additional payment information is identified, the set of the data to be requested is formed in the payment platform and redirected to Payment Page. 2. The page for entering the requested data is displayed to the customer. 3. The customer enters the requested data. 4. The data specified by the customer is transferred to the payment platform. 5. The received data is processed in the payment platform, and after that payment processing continues in its ordinary way. ## Usage specifics {#section_vmd_mjd_4mb .section} When configuring time limit for using Payment Page, you should take into account that the time for submitting additional payment information is included in the common time for using the payment form.Hence, when you configure the time limit for using the payment form, you need to take into consideration the time of possible submission of additional data. If the restriction is not set, waiting time for submitting additional payment information is set by default, it is 30 minutes starting from the moment of identifying the need for additional data. In both cases, if the additional information is not provided before the remaining time expires, payment is automatically declined. To monitor payments that involve submission of additional information, you can use notifications and information provided in the payment information tabs in Dashboard \(for more information, see [Monitoring and performing payments](en_dbl_payments.md#)\). Intermediate and final notificationssent from the payment platform contain the set of data requested from the customer in terms of submitting additional payment information. Intermediate notifications also contain the status of the payment \(`awaiting_clarification`\), which remain until the customer payment data is received. The following is an example of a callback with the request of additional data \(customer address\) required for continuation of card payment processing. ```language-json { "project_id": 1173, "payment": { "id": "15557465346", "type": "purchase", "status": "awaiting clarification", // payment status "date": "2020-07-30T10:20:58+0000", "method": "card", "sum": { "amount": 131970, "currency": "USD" }, "description": "" }, "account": { "number": "431422******0056 ", "type": "visa", "card_holder": "JOHN DOE", "expiry_month": "01", "expiry_year": "2023" }, "customer": { "id": "3b6d6827-8cdd-4040-aaf6-0a8f81b95c31" }, "clarification_fields": { // the requested data "avs\_data": \[ "avs\_address" \] }, "operation": { "id": 72658000000461, "type": "sale", "status": "awaiting clarification", "date": "2020-07-30T10:20:58+0000", "created_date": "2020-07-30T10:20:58+0000", "request_id": "c0f65543b97c062cf172cf04df239ee16ae27b34-9b1943e6454385d28d4f975bfd397aef6aa55a71-00072659", "sum_initial": { "amount": 131970, "currency": "USD" }, "sum_converted": { "amount": 131970, "currency": "USD" }, "code": "9999", "message": "Awaiting processing", "eci": "00", "provider": { "id": 414, "payment_id": "", "endpoint_id": 414 } }, "signature": "oFcRanmZ5FrWt8zQWqHM15PPWKV5eAfIErQXBS/1uMwzF1..." } ``` **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Payment retries {#en_PP_Try_Again .concept} An article about the capability of providing customers with additional payment attempts via Payment Page if the previous attempt to pay has failed, with the option to select the payment method. ## Overview {#section_ovx_sqn_smb .section} When making payments using Payment Page, customers usually need one attempt to complete the payment, but sometimes they have to repeat the procedure—for example, when there are insufficient funds on the payment card the customer is using to make the purchase. In such cases, the Ecommpay payment platform provides the capability of retry attempts to make one payment \(a payment with the same identifier\) during a single session on Payment Page. Generally, if the payment has been declined, the final page of the payment form with an error message is displayed to the customer. In this case, without the functionality of payment retries, the Payment Page session is completed, and, to repeat the attempt, the customer has to go back to the web service to initiate a new payment. With the capability of retry attempts set up, if the payment fails, it can be attempted again within a single session; in this case, the error message and the button for retrying the payment are displayed on the final page of the payment form. || **Note:** Cookies are required for the emulator to function properly. The emulator will not load without cookies. Since all retry attempts are made within a single Payment Page session, the parameters specified in the request for opening Payment Page remain unchanged for all subsequent attempts.This also applies to cases when [payment methods or method groups are preselected](en_PP__PreselectingPS.md). Overall, when the payment retries functionality is used, the options of payment method selection are determined as follows. |Preselected payment method or method group|First attempt|Each retry attempt| |------------------------------------------|-------------|------------------| |–\(none\) |any payment method available|depending on the action performed during the first attempt:- processing a purchase—any of the payment methods available for making a purchase - placing an authorisation hold—any of the payment methods available for performing an `auth` operation | |card payments|card payments|card payments or \(if agreed upon and set up\) Apple Pay or Google Pay| |alternative payment method\(group of methods\) |specified method\(group of methods\) |specified method\(group of methods\) | **Note:** Keep in mind the following considerations for payment method selection when using the functionality: - If the payment method has not been preselected, should the customer decide to retry the payment, they can choose one of the payment methods that support the type of the operation performed during the first attempt. For example, if the first attempt involved placing an authorisation hold as part of performing a two-step purchase \(`auth`\), then for every subsequent attempt the customer can select the method for which two-step purchases are supported, so that the authorisation hold is performed instead of the withdrawal of funds \(`sale`\). - If card payments are preselected and such option has been set up for the project, the customer can choose to retry the payment not only with the card but also with Apple Pay or Google Pay. This option is set up separately, upon agreement with your Ecommpay account manager. - If you specify one of the alternative payment methods in a payment request, all subsequent retry attempts are performed with the use of this method. Another payment method cannot be selected. - If you provide a payment card token in a payment request, all subsequent retry attempts are performed with the use of this token. Another payment method or payment instrument cannot be selected. The number of attempts and the time allocated for executing these attempts are limited. These restrictions can be configured upon coordination with your account managerand apply to all payments within a project for which the functionality of payment retries is set up. ## Usage scenario {#section_ehh_2rn_smb .section} The following steps present the customer procedure of making a purchase with the capability of retry attempts: 1. The customer confirms the purchase in the merchant web service. 2. The customer is redirected to Payment Pagewhich is generated according to the parameters specified in the request for opening Payment Page. The customer performs the required actions and waits for the purchase result. 3. After the purchase has failed, the final page of the payment form with the button for retrying the payment is displayed to the customer.Upon clicking the button, the customer is redirected to step 2. 4. After the payment has been completed, the information is displayed on the standard final page of the payment form\(without the button for retrying the payment\). ## Special aspects {#section_ft3_qrn_smb .section} If you want to set up the functionality of payment retries, consider the following aspects: - *The requirement to display the final page of the payment form.*With the functionality of payment retries, the final page with the payment result must be displayed to the customer. If automatic customer redirection to the web service is set up, the customer cannot retry the payment. For more information, see [Options for redirecting customers to the web service](en_PP_redirect_modes.md#). - *Support for Payment Page customisation.* If the payment form design is implemented on the basis of another interface model \(not the basic one\), coordinate with the Ecommpay account manager the implementation of an additional element on the payment form—the button for redirecting the customer to a payment attempt—and, if necessary, provide the corresponding template layout to the technical support specialists. - *The time limit for repeating payment attempts.* The countdown for all retry attempts begins at the moment when the payment failure is registered in the payment platform for the first time. In this case, the timer is not displayed on Payment Page. However, if there is a time limit for making this payment via Payment Page \([details](en_pp_time_limit.md)\), the customer can see the timer counting down the amount of time allowed for this payment. At this point, the time restriction on the payment attempts is ignored.In any of the above cases, ifthere have been no successful retry attempts over the time allocated for using Payment Page, the payment is declined, and the final page with the corresponding notification is displayed on the payment form. ## Setup {#section_mly_s5s_hpb .section} To have the capability of retry attempts set up, merchants should complete the following steps: 1. Coordinate the process with your Ecommpay account manager: discuss the setup procedure and whether it is necessary to test the functionality. Also consider the restrictions on the number of attempts and the time allocated for making the attempts.These limits apply to all payments within the project and can be configured by the Ecommpay specialists according to the needs of merchants. Usually, such restrictions are set to 5 attempts that must be performed within 10 minutes. 2. If it was agreed that testing is required, wait to be notified by the Ecommpay specialists when the functionality is ready, thentest the payment form workflow with the new capability.After that inform the account manager that you are ready to launch the functionality in your production environment. 3. Receive the notification from the Ecommpay specialists about the completion of the capability setup. ## Workflow {#section_mlr_1vs_hpb .section} The following diagram illustrates the payment retries workflow: ![](images/en_pp_try_again_uml.svg) 1. If the purchase has not been completed with the debiting of fundsor authorisation hold, it is checked if retry attempts are available for making the purchase within the project. 2. An intermediate callback with the information about the capability is sent from the payment platform to the web service. 3. The information about the availability of payment retries is transmitted from the payment platform to Payment Page. 4. The final page of the payment form is shown to the customer. It displays the message stating that the purchase has been declined. The page also contains the button for redirecting the customer to an additional payment attempt. 5. The customer agrees to retry the payment and performs the required actions. 6. After the customer payment data is transmitted to the payment platform, a retry is initiated with the use of this data. When payment retries are processed, the payment status can vary: - `processing`—checking for the availability of retry attempts in case the purchase fails\(when step 1 on the diagram is performed\) or upon receiving payment data from the customer within the scope of the current retry attempt\(after step 6 is performed\). - `awaiting customer`—waiting for the customer actions. The status remains from the moment when the availability of retry attempts is identified within the payment platform\(at step 1\) and until the customer payment data is received \(after step 6 is performed\)or until the attempt time limit expires \(in this case, the payment gets the `decline` status\). - `success`—the required action has been completed \(one of the retries has resulted in the debiting of fundsor authorisation hold\). - `decline`—all the possible retries have failed \(none has led to the debiting of fundsor hold on funds\) or the time allowed for the attempts has expired. The same status is assigned when the customer declines to repeat the attempt. All possible payment statuses used within the platform are described in [Payment processing](en_platform_payment_model.md). ## Callbacks {#section_kxm_2ws_hpb .section} During the process of payment retries, intermediate and final callbacks are sent from the payment platform to the web service. *Intermediate callbacks.* If the purchase has failed and the availability of retry attempts has been identified, an intermediate callback is sent from the payment platform to the web service. This callback contains information about the availability of retry attempts \(specified in the `is_new_attempts_available` parameter\) and the remaining time allowed for these attempts \(specified in the `timeout_attempts` parameter in seconds—`ss`\). In the intermediate callbacks, the `is_new_attempts_available` parameter is set to `true`, which implies that all of the following conditions have been met: - None of the attempts has led to the completion of the payment. - There are available attempts. - The time for executing the attempts has not expired. In the following example of the callback body, you can see that for the purchase with the identifier `100028024` repeating payment attempts is allowed \(`is_new_attempts_available = true`\) and the time limit for the attempts is set to ten minutes \(`attempts_timeout = 600`\). ```language-json { "project_id": 212, "payment": { "id": "100028024", "type": "purchase", "status": "awaiting customer", // payment status "date": "2020-07-21T17:51:04+0000", "method": "card", "is_new_attempts_available": true, // availability of retry attempts "attempts_timeout": 600, // remaining time "sum": { "amount": 131970, "currency": "USD" }, "description": "" }, "account": { "number": "431422******0056 ", "type": "visa", "card_holder": "JOHN DOE", "expiry_month": "01", "expiry_year": "2025" }, "operation": { "id": 20759000013841, "type": "auth", "status": "decline", "date": "2020-07-21T17:51:04+0000", "created_date": "2020-07-21T17:20:55+0000", "request_id": "7ba0fb24436a717d3091f7b71007891696db6e-00020760", "sum_initial": { "amount": 131970, "currency": "USD" }, "sum_converted": { "amount": 131970, "currency": "USD" }, "code": "108", "provider": { "id": 414, "payment_id": "", "endpoint_id": 414 } }, "signature": "oXlx8QWh3OC/YOqb2ib3C5jq/lHvisceI9Lqg/tRTuwcrNmj1zQ..." } ``` *Final callbacks.* If the payment has been completed or cannot be completed within the session, a final callback is sent from the payment platform to the web service.In this case, the `is_new_attempts_available` parameter is set to `false` due to one of the following conditions: - The final attempt has led to the completion of the payment. - The customer has declined to repeat the attempt. - All the available payment attempts have been used up. - The time for making the attempts has expired. In the following example of the callback body, you can see that the time for performing retries has expired and the purchase has been declined. ```language-json { "project_id": 212, "payment": { "id": "100028024", "type": "purchase", "status": "decline", // payment status "date": "2020-07-21T17:51:04+0000", "method": "card", "is_new_attempts_available": false, // availability of retry attempts "attempts_timeout": 0, // remaining time "sum": { "amount": 131970, "currency": "USD" }, "description": "" }, "account": { "number": "431422******0056 ", "type": "visa", "card_holder": "JOHN DOE", "expiry_month": "01", "expiry_year": "2025" }, "operation": { "id": 20759000013841, "type": "auth", "status": "decline", "date": "2020-07-21T17:51:04+0000", "created_date": "2020-07-21T17:20:55+0000", "request_id": "7ba0fb24436a717d3091a2bdf7891696db6e-00020760", "sum_initial": { "amount": 131970, "currency": "USD" }, "sum_converted": { "amount": 131970, "currency": "USD" }, "code": "603", "message": "Auto decline", "provider": { "id": 414, "payment_id": "", "endpoint_id": 414 } }, "signature": "oXlx8QWh3OC/YOqb2ib3C5VLPksceI9Lqg/tRTuwcrNmj1zQ..." } ``` **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Collecting customer data {#en_PP_Gathering_customer_data .concept} An article about the capability of obtaining and using additional customer information during payment processing via Payment Page to minimise the need for auxiliary procedures. ## Overview {#section_ivk_bpf_gdb .section} In some cases, along with data mandatory for payment processing, you may need to collect additional information from your customers, for example, their phone numbers or email addresses. Collecting such data can be useful as it allows merchants to: - Provide an extra layer of payment security by collecting and verifying customer information. - Improve user scenarios by avoiding the necessity to submit additional payment information \(when it is requested by payment providers,payment systems, and banks during payment processing—[learn more](en_pp_clarification.md)\). The capability of collecting additional data is supported directly in the Payment Page payment form and, for certain payment methods, in the associated payment services \(such as Apple Pay, for example\).Keep in mind that collecting additional data increases the number of actions required from the customer to make a payment and can negatively affect the payment form conversion. Therefore, this capability should be used only when it is clearly necessary. In most cases, the optimal solution is to submit previously collected information about customers in the requests for opening Payment Page. To work with additional data provided by customers on the payment formor in the third-party services, you can use payment information tabs in the Dashboard interface and final callbacks with the information about operation processing. To set up passing customer data in callbacks, contact the Ecommpay technical support. ## User scenarios {#section_wks_zfs_jsb .section} A number of fields can be used to collect additional customer data on the payment form. These fields can be displayed at all times or only when necessary and can be required or optional. Along with that, the placement of these fields can differ: they can be located on the page where customers enter payment information or on the separate page that follows \(depending on the total number of fields\). The way each field is displayed depends on its specific properties and what data is submitted in the request for opening Payment Page. The following display options are available for each of the additional fields: - `1`—the field is displayed with the prefilled value that was specified in the request. The customer can change this value. - `2`—the field is displayed and is left blank, but contains a name of the field. - `3`—the field is not displayed. The field value can be submitted to the payment platform only via a request. ![](images/ecommpay/en_pp_gathering_customer_data.svg "Additional fields display options") The field display option is determined as follows. |This parameter is required|+|+|+|+|–|–|–|–| |This field must be displayed|+|+|–|–|+|+|–|–| |The field value is passed in the request|+|–|+|–|+|–|+|–| |**Field display option**|**`1`**|**`2`**|**`3`**|**`2`**|**`1`**|**`2`**|**`3`**|**`3`**| To collect additional data via third-party services such as Apple Pay and Google Pay, the interfaces provided by these services are used. Depending on their specifics, requesting customer data may involve, for example, using information previously saved by the customer or other special features of interaction. Note that all requested details must be provided and data requests can be configured both via project-level properties and through individual request parameters. For instance, you can set collecting customer email addresses as a default via project properties and collect other types of data when necessary through request parameters \(learn more in the articles on payment methods [Apple Pay](pm_applepay.md#) and [Google Pay](pm_googlepay.md#)\). The data collected thereby can be sent to the merchant's web service in the payment result callbacks. To enable this functionality, contact the Ecommpay technical support specialists. ## Setup {#section_ts1_3sf_gdb .section} To have the capability of collecting customer data enabled, you should: 1. Decide which projectsand which payment methods supported for these projects may warrant the collection of additional customer data. For each case, determine what data needs to be requested and define the properties of the fields in question. Additional customer data may include a range of parameters \(to learn more, [see below](en_PP_Gathering_customer_data.md#section_jdb_1qx_tdb)\) while the properties of each field are the following: - The field can be required or optional to fill in and/or display. - It is a text or dropdown input field. To use a dropdown input field, for example, to collect *the name of the country*, you should provide the support specialists with all possible values for this list or coordinate and approve the use of definitions from the reference sources provided by Ecommpay. - Its name: by default standard names are provided by Ecommpay; however, customisation is available. If you would like to add customised field names, provide the support specialists with the translations into all languages used for the project. 2. Make sure that the technical support specialists have all the details about customer data to be collected as well as the information whether any of these parameters specified by customers on the payment form should be passed in final callbacks. 3. Get notified by the Ecommpay specialists that the requested functionality has been enabled and test the work of the payment form with this capability if necessary. ## Collected data {#section_jdb_1qx_tdb .section} The following parameters can be used for collecting customer data. |Parameter|Description| |---------|-----------| |customer\_address string |The name of the street and the house number \(including any additional parts of the address such as building indicators and apartment numbers\) in the customer's address, separated by a comma. A string, must not exceed 255 characters. Example: `29 Arlington Avenue, Islington` | |customer\_birthplace string |Customer's place of birth A string, must not exceed 255 characters. Example: `Cambridge` | |customer\_city string |Customer's city of residence. A string, must not exceed 255 characters. Example: `London` | |customer\_country string |Code of the customer's country in ISO 3166-1 alpha-2 format. Example: `GB` | |customer\_day\_of\_birth string |Customer's date of birth in `DD-MM-YYYY` format. Example: `11-03-1952` | |customer\_email string |Customer's email address. A string, must not exceed 255 characters, must contain two parts: the username and the domain name separated by the @ symbol. Example: `dna@douglasadams.com` | |customer\_first\_name string |Customer's first name. A string, must not exceed 255 characters. Example: `Douglas` | |customer\_last\_name string |Customer's last name. A string, must not exceed 255 characters. Example: `Adams` | |customer\_middle\_name string |Customer's middle name or patronymic. A string, must not exceed 255 characters. Example: `Noel` | |customer\_phone string |Customer's full phone number, with the country code. Technically, the number must include from 4 to 24 digits, and if it is allowed within the project and payment method used, punctuation marks and special symbols may be used while specifying the number \(such cases are usually mentioned separately\). Examples: `443031237300` | |customer\_ssn integer |Last four digits of the Social Security number used for taxpayer identification, income reporting, and record-keeping purposes in the USA. Example: `4942` | |customer\_state string |Customer's region or state. A string, must not exceed 255 characters. Example: `London` | |customer\_zip string |Customer's postal code. A string, must not exceed 10 characters. Example: `N17BL` | |billing\_address string |Street of the customer's billing address. A string, must not exceed 255 characters. Example: `Arlington Avenue` | |billing\_city string |City of the customer's billing address. A string, must not exceed 255 characters. Example: `London` | |billing\_country string |Code of the country associated with the customer's billing address in ISO 3166-1 alpha-2 format. Example: `GB` | |billing\_postal string |Postal code of the customer's billing address. A string, must not exceed 16 characters. Example: `N17BL` | |billing\_region string |Region or state of the customer's billing address. A string, must not exceed 255 characters. Example: `London` | |billing\_region\_code string |Code of the region associated with the customer's billing address in ISO 3166-2 format. Example: `LND` | If you need to use parameters not listed in the table above, contact the Ecommpay specialists. **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Interface language support {#en_PP_WigetLanguages .concept} An article about the capabilities of specifying the language used when the payment form is displayed. ## Overview {#section_hjd_lgb_sqb .section} The Payment Page text elements—various names \(including names of fields and other\), hints and messages \(including error messages\)—are the integral part of the payment form. These elements make the interface complete and clear and can have a significant impact on the user experience and the payment form conversion. ![](images/ecommpay/pp_wigetlanguages_1.svg) ## Capabilities {#section_zsf_pgb_sqb .section} In order to ensure the effectiveness of the Payment Page texts, the Ecommpay specialists work thoroughly on the content localisation and provide the capability of using any of the Payment Page languages from the regularly expanded [basic set](en_PP_WigetLanguages.md#section_ajn_r3b_sqb), while in the form customers can select any of the available languages. Along with that, due to different business nuances and for a better adaptation of Payment Page to a specific project, the merchant can discuss with the Ecommpay account manager the possibility to augment the list of available languages and specify the language relevant to a specific invocation of the payment form\(using the customer's web service language preference, for example\). ![](images/ecommpay/pp_wigetlanguages_2.svg "Using the capability of changing the language") In addition, it can be relevant to change the payment form design using the corresponding [design builder](en_PP__design_customisation.md#). ## Workflow {#section_x4l_1hb_sqb .section} Every time the payment form opens, the customer can change the language of its interface to any of the basic set. Along with that, the form opens in the following default language \(the options are provided in order of priority\): 1. The language of the payment form interfacethat was specified in the request for opening the form\([details](en_PP_WigetLanguages.md#section_ivb_h3b_sqb)\)—this language is used if it is supported for the project, and if it is not supported, then the default language \(English\) is used. 2. The customer’s browser language—this language is used if it has been identified\(via browser properties\) and is supported for the project. 3. English \(used as a default language\). ## Specifying a language when opening the payment form {#section_ivb_h3b_sqb .section} In order to localise the payment form for a particular session, submit the request for opening the payment form with the code of this language specified in the `language_code` parameter.Within the payment platform, the codes are passed in the alpha-2 format of the [ISO 639-1](https://www.iso.org/iso-639-language-codes.html) standard, the codes of the languages that are not covered by the standard are coordinated with the merchant.It should be noted that the language set for invoking the form will also be used to generate additional notifications regarding events related to the payment \(if this functionality is enabled in the project settings; see [this article](en_gate_receipts.md#)\). ```language-json { "project_id": 93211, "payment_id": "423289", "payment_currency": "EUR", "payment_amount": 131970, "customer_id": "customer_772", "language_code": "de", // language code "signature": "TSzdE5rJZaA9TYAWEKoGpfXriFf82MxF..." } ``` This method of specifying the language means that it will determine the language of the payment form interface and the language of [notifications and payment receipts](en_PP_receipt_data.md) \(if applicable\). However, if the specified language falls outside the project's supported language set, then English is used as the default. ## Basic set of languages {#section_ajn_r3b_sqb .section} Ecommpay supports displaying the payment form in the following languages. |Language|Language code| |--------|-------------| |English|`en`| |Estonian|`et`| |French|`fr`| |German|`de`| |Italian|`it`| |Latvian|`lv`| |Lithuanian|`lt`| |Portuguese|`pt`| |Spanish|`es`| |Ukrainian|`uk`| **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Preselecting payment methods {#en_PP__PreselectingPS .concept} An article about the capability of preselecting a specific payment method when invoking the payment form. ## Overview {#section_cf5_jxk_ymb .section} By default, the customer's payment procedure on Payment Page begins at the step of selecting a payment method. However, in some cases, there is no need to display the payment form with the page for payment method selection. This may be the case when the customer selects a payment method in the merchant web service before opening Payment Page or when paying with a particular method is relevant for this merchant due to region- or customer-specific reasons and other factors. The Ecommpay payment platform provides the capability of opening Payment Page with the payment method that has been preselected by the customer or the merchant.With this functionality configured, the page for selecting a payment method is not displayed to the customer on the payment form. For a payment method to be preselected, this method is specified in the request for opening Payment Page—no additional actions are required for setting up this functionality. ![](images/ecommpay/en_pp_preselectingps_1.svg "Standard scenario—the payment method is selected by the customer on the payment form") ![](images/ecommpay/en_pp_preselectingps_2.svg "Augmented scenario—the payment method is preselected before the payment form opens") The functionality of preselecting a payment method can be accompanied by other possible capabilities, which are relevant for certain payment methods andaffect the Payment Page workflow. Here are some of such capabilities in particular: - *Displaying details of saved cards issued for a certain payment system.* With card payments, it is possible to limit the choice of cards that were previously saved by the customer. For this, the request for opening Payment Page should contain the identifier of the preferred payment system \(for example, Mastercard or Visa\). As a result, the customer payment procedure begins on the page with the list of the previously saved cards that were issued for the payment system specified in the request. If the customer has not saved the card data before or the list of saved cards does not contain the data the customer needs, the customer can specify the details of another card which can also be the card issued for a different payment system. ![](images/ecommpay/en_pp_preselectingps_3.svg) - *Preselecting banks for online banking payments*. When working with an online banking payment method\(for example, the [Indonesian Online Banking](pm_indonesia.md#) method\), merchants can preselect a particular bank that works with the specified payment method. In this case, the customer is redirected straight to the bank website without being redirected to the pages for selecting a payment method and a bank.The information about such capability that is relevant for particular payment methods is provided in the [Methods](en_pm_about.md) section. - *Preselecting payment method groups*. Some methods, such as [Open Banking in Germany](pm_germany.md#) are included in groups whose identifiers can be specified when sending for opening Payment Page. In this case, the customer is shown buttons for selecting only those methods that are included in the specified group and are available within the project being used. Finally, besides preselecting a certain payment method, merchants can manage the availability of payment methods on Payment Page. For more information about this capability, see [Managing payment methods availability](en_pp_methods_availability.md#). ## Special aspects {#section_a4b_vxk_ymb .section} If you want to set up the functionality of preselecting a payment method, consider the following aspects: - Preselecting a payment method is supported only for the methods that are available within the current project, otherwise, the request for opening Payment Page is declined. - The customer cannot select a payment method different from the one that was specified in the request for opening Payment Page; this also applies to the procedure of [payment retries](en_PP_Try_Again.md)—with a payment method preselected, the customer cannot select a payment method when making additional payment attempts within a single Payment Page session. - If the request for opening Payment Page contains both a payment method and a token, the payment is processed with the use of this tokenand the information about the specified payment method is ignored. ## Request format {#section_km2_xxv_spb .section} The preselected payment method should be specified in the request for opening Payment Page. For this, the code of this payment method should be specified in the `force_payment_method` parameter in the request, while to preselect a payment method group, specify the code of the group in the `force_payment_group` parameter. For more information about the codes of the supported payment methodsand groups, see [this reference](en_pm_codes.md). The following example illustrates the parameters passed in the request for making a purchase with the Alipay payment method. ``` { .language-json .show_more} { "project_id": 42, "payment_id": "456789", "payment_currency": "USD", "payment_amount": 131970, "customer_id": "customer_12", "force_payment_method": "alipay", // payment method code "signature": "TSzdE5rJZaA9TYAKoGpfXriFf82MxF..." } ``` ```language-json { "project_id": 42, "payment_id": "456789", "payment_currency": "USD", "payment_amount": 131970, "customer_id": "customer_12", "force_payment_method": "alipay", // payment method code "signature": "TSzdE5rJZaA9TYAKoGpfXriFf82MxF..." } ``` If you need to specify a certain payment system for a card payment, the request for opening Payment Page should contain the following: - The `force_payment_method` parameter with the value `card` \(the code of the card payment method\) specified. - The `force_payment_method_subtype` parameter with the identifier of the payment system specified. The list of the identifiers of the supported payment systems is provided in [Payment card codes](en_card_codes.md). The following example illustrates the parameters passed in the request for making a payment with Mastercard specified as the preferred payment system. ``` { .language-json .show_more} { "project_id": 43, "payment_id": "456790", "payment_currency": "USD", "payment_amount": 131970, "customer_id": "customer_12", "force_payment_method": "card", // payment method code "force_payment_method_subtype": "mastercard", // payment system identifier "signature": "TSzdE5rJZaA9TYAKoGpfXriFf82MxF..." } ``` ```language-json { "project_id": 43, "payment_id": "456790", "payment_currency": "USD", "payment_amount": 131970, "customer_id": "customer_12", "force_payment_method": "card", // payment method code "force_payment_method_subtype": "mastercard", // payment system identifier "signature": "TSzdE5rJZaA9TYAKoGpfXriFf82MxF..." } ``` ## Related links {#section_e3z_tyv_spb .section} - [Payment method codes](en_pm_codes.md)—the reference section with the list of codes for the supported payment methods. - [Payment card codes](en_card_codes.md)—the reference section with the list of identifiers for the supported payment systems. - [Managing payment methods availability](en_pp_methods_availability.md#)—the section with the information about limiting the list of payment methods for a particular payment. - [Methods](en_pm_about.md)—the section with the information about the payment methods that are supported within the platform. - [Payment Page API specification](en_PP_Parameters.md)—the section with the information about parameters that are used for opening Payment Page. **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Arranging payment methods on the page {#en_pp_methods_order} An article about the capability of arranging payment methods on the form to be presented to the customer in the optimal order. ## Overview {#section_rr3_3cy_txb .section} When processing payments via Payment Page, *dynamic* or *static* ordering of the payment method buttons can be applied on the payment method selection page. Dynamic ordering is used by default. It implies that payment methods are arranged on the page according to their relevance for the current session of opening the payment form. The following data are factored in when calculating relevance: - the customer's location - the merchant's business type - the frequency of various payment methods selection within the project **Note:** It is also important to mention that when mSDKs are used, payment methods are sorted based on the data received from mobile devices while in all other cases it is the data received from all other devices but mobile. At the same time, if needed, you can choose to have payment method buttons arranged in a fixed order\(for instance, alphabetically\) on the payment method selection page. To set up this option, contact the technical support. ## Use cases {#section_s54_3cy_txb .section} Here are several examples to compare the options. - If a customer from Portugal places an order on the website of the merchant with business operations in Europe, then applying the option of dynamic ordering arranges the methods from more relevant in Portugal for the merchant's business type and specific project \(Multibanco and Open Banking in Portugal\) to less relevant \(Astropay and Open banking in France\). - If a customer from France places an order on the website of the same merchant, then the methods are arranged from more relevant in France for the merchant's business type and specific project \(Open banking in France, Google Pay\) to less relevant \(Astropay, Open banking in Portugal, Multibanco\). - If static ordering is applied, then for both cases described above payment methods are arranged in a fixed order. ![](images/ecommpay/pp_methods_order_1.svg "Dynamic ordering when the customer is in Portugal") ![](images/ecommpay/pp_methods_order_2.svg "Dynamic ordering when the customer is in France") ![](images/ecommpay/pp_methods_order_3.svg "Static ordering") **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Saving customer payment data {#en_PP_saved_data .concept} An article about the capabilities of saving and using the customer payment data when working with the payment form. To ensure convenience and efficiency of the Payment Page user scenarios, you can implement the capability of storing customer payment credentials for subsequent use without prompting the customer to provide this data again. Customer payment credentials can be saved when customers make purchases or when their payment instruments are verified.Saved payment credentials are shown on the payment method selection page together with the details of cards for which tokens were generated. Payment Page supports the following options for saving payment data: - always save customer payment data - never save customer payment data - ask customers about saving payment data Additionally, you can limit the maximum number of saved payment instruments per customer. If necessary, the customer can delete saved payment instruments in Payment Page. In case when the customer deletes a saved card that was used to register a COF purchase, the debiting of funds continues to take place. For details on cancelling a COF purchase, see [COF purchase registration](en_pp_recurring.md). **Note:** To enable and configure the service contact technical support by email [support@ecommpay.com](mailto:support@ecommpay.com). **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Payments by using tokens {#en_PP_Payment_by_token .concept} An article about the capability of using payment data tokens to reduce the number of steps in customer payment scenarios. Payment Page supports performing fast payments by using bank card tokens. While requesting to open a payment page you specify the active token of a customer bank card. The generated payment page opens with the filled bank card details \(except CVV\). To make a payment, the customer enters only CVV and confirms the payment amount by clicking **Pay**. **Note:** When performing a payment by using a token the customer will not be able to select any other bank cardor payment account. ![](images/ecommpay/en_pp_payment_by_token.svg "Payment page with preselected card when performing a payment by token") **Note:** The functionality is available in the Purchase mode. **Note:** To enable and configure the service contact technical support by email [support@ecommpay.com](mailto:support@ecommpay.com). ## Parameters to pass {#section_wpx_yfk_5bb .section} To perform a payment by token, specify the token in the account\_token parameter and the ID of a customer in the customer\_id parameter in the object or the URL. For the full list of the supported parameters see [Payment Page API specification](en_PP_Parameters.md). **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Currency conversion {#en_pp_currency_conversion} An article about the capability of processing payments via Payment Page in different currencies with currency conversion. ## Introduction {#section_whs_hw2_ngc .section} The Ecommpay payment platform supports payments in multiple currencies with automatic conversion\(when payment amounts are recalculated according to the exchange rate between two currencies\). You can configure the following optionsto make payments more flexible and convenient: - Setting up [balances](en_glossary.md#) in different currencies. - Configuring [payment methods](en_glossary.md#) and [channels](en_glossary.md#) in different operating currencies. - Allowing your customers to select the currency of the purchase in your web service or directly in Payment Page \([details](en_pp_currency_choice.md)\). Using each of the aforementioned options can be limited due to the specifics of the way partners and providers operate, regional specifics, and other factors. However, in most cases these options let you adapt this functionality to your business model and use both local and global currencies efficiently. For information about setup and use, refer to this and other articles on the documentation portal, or contact your Ecommpay account manager. ## Conversion scenarios {#section_sxy_3y2_ngc .section} Processing a payment via the Ecommpay platform can involve four kinds of currency: - *Requested payment currency*—the currency specified by the merchantin the initial payment request. - *Actual operational currency \(can also be referred to as settlement currency\)*—the currency used in the platformfor processing the payment and determined on the basis of various factors. - *Payment instrument currency*—the currency of the customer’s payment instrumentused for making a payment. - *Balance currency*—the currency of the merchant’s balanceassociated with the payment. If all these currencies are the same, no conversion is required. If at least one differs, conversion is necessary, since the payment cannot be completed otherwise. ![conversion_scheme](images/en_pp_conversion_gbp.svg) For example, a customer in Poland pays with a card denominated in Polish zloty \([PLN](references/en/currencies/PLN.md)\) for a service in Norway. By default, the available payment channel supports Norwegian krone \([NOK](references/en/currencies/NOK.md)\), while the merchant's balance is in pounds sterling \([GBP](references/en/currencies/GBP.md)\). If the merchant's integration does not have additional options configured, the payment requires double conversion: - For the customer, the payment amount is converted from [PLN](references/en/currencies/PLN.md) to [NOK](references/en/currencies/NOK.md) by the issuer. - For the merchant, the payment amount is converted from [NOK](references/en/currencies/NOK.md) to [GBP](references/en/currencies/GBP.md) by Ecommpay. However, if in this integration there is an available payment channel in British pounds, then this payment can be processed in pounds, without conversion from the operational currency to the balance currency. If there is an available payment channel in zloty, then this payment can be processed in pounds, without conversion from the payment instrument currency to the operational currency. Thus, supporting payment channels and balances in different currencies allows for greater flexibility in payment processing and can eliminate the need for additional steps with currency conversion. At the same time, in the Ecommpay platform, there are also practical considerations regarding the use of multiple balances and the constraints that come into play when different payment methods, channels, and balances are involved. When payments are processed, the currency conversion is performed automatically, as deemed necessary.Keep in mind that the actual operational currency is determined in the platform each time based on the request parameters, customer's preference for the payment currency \(if applicable\), project and payment method settings\(including the preferences for currencies and channels indicated by the merchant\), and the availability of payment channels. In addition, currency conversion can also be performed on the side of the web service before the request is sent to the payment platform, with the use of the merchant's exchange rates and under their own terms and conditions. ## Choosing the currency {#section_ndp_qbf_ngc .section} When working via Payment Page, you can decide on the way your customers will select the currency of the payment, and the options are as follows. - *Choosing the currency in the web service*—customers choose the currency they prefer before Payment Page is opened.Conversion is performed on the web service side. The selected currency becomes the *requested payment currency* and is processed accordingly by the platform. This option is available by default for all payment methods and currencies. - *Choosing the currency in Payment Page*—customers choose the currency they prefer directly in Payment Page\([details](en_pp_currency_choice.md)\). Conversion is performed on the Ecommpay side. The currency specified in the request remains the initial *requested payment currency*, while the currency chosen by the customer becomes the *selected payment currency* and takes priority for processing. By default, it also acts as the *actual operational currency* for the payment.This option is available only for some payment methods and supported currencies for these methods. ## Monitoring payments with currency conversion {#section_c2b_gcf_ngc .section} To monitor the use of various currencies and currency conversion during payment processing, you can rely on various tools including: - Payment result callbacks \([details](en_platform_callbacks.md#)\). - Consolidated registers and payment information tabs in the Dashboard interface \([details](en_dbl_payments.md#)\). - Information about operations retrieved via the Data API \([details](en_dbl_using_api.md#)\). - Financial statements. Note that when conversion is performed by the Ecommpay payment platform, the applied exchange rates are determined dynamically based on the market data provided by specialised partner organisations. For any questions regarding these rates, applicable fees, or the use of conversion in specific cases, please contact your Ecommpay account manager. **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Currency choice in Payment Page {#en_pp_currency_choice} An article about the capability of letting customers choose payment currency that fits their needs in the payment form. ## Overview {#section_v54_bdt_whc .section} In certain cases you may find it useful to give your customers a possibility to choose the payment currency that fits their needs directly in the payment form. When accepting payments via Payment Page, you can set up payment processing workflows where this capability is integrated seamlessly, with support for a wide range of available currencies, flexible configuration, and automatic currency conversion when necessary. ![](images/ecommpay/en_pp_conversion_1.svg "Selecting currency out of all available when paying with a card") ![](images/ecommpay/en_pp_conversion_2.svg "Selecting out of relevant currencies when paying with a card") ![](images/ecommpay/en_pp_conversion_3.svg "Selecting out of available currencies when paying with Google Pay") With this capability, the currency that was specified in the request to open Payment Page is always shown as preselected. However, the customer can choose to pay in one of the other available currencies, in which case the customer is then shown the recalculated payment amount in the currency they selected and are able to confirm the payment in the selected currency. Choosing the currency in the payment form is supported, first and foremost, for the globally accepted payment methods: Apple Pay, Google Pay andstandard card payments. If you have any questions regarding the integration, setup, and use of this functionality, refer to your Ecommpay account manager. ## Special aspects and limitations {#section_jjt_zht_whc .section} When integrating and using the functionality of choosing the currency in the payment form, consider the following special aspects and limitations: - *Payment methods that support currency choice must be available for selection by button on the payment method selection page.* For instance, in case of the Apple Pay and Google Pay payments, this option is supported if the buttons to select these methods are shown on the payment method selection page.Then the payment method can be either preselected, by your specifying its code in the payment request, or selected directly in the payment form by the customer, following which the customer can select the currency. If these buttons are shown on the page to enter card details, it means these methods serve in the interface as complementary options to a standard card purchase and cannot be selected separately from card payments, and this currency selection option is not available. - *The customer selects the currency only out of those that are available. You can manage the availability of currencies for selection.* In general, available currencies encompass all currencies supported as operational for the merchant's project in question and also available for performing conversion within the initiated payment session. For card payments, the currency availability can be limited by filtering all available currencies. The options are as follows: - Selecting currency out of all available. This option is supported for Apple Pay, Google Pay, and standard card payments. - Selecting currency out of those relevant for the country where the card was issued \(determined by the card number\) or, if relevant currencies are not available, out of the remaining available currencies. For example, if the customer uses the card issued in Brazil, and the Brazilian real is supported as an operational currency for the project in question, the available currencies can be the initial currency specified in the request and the Brazilian real. This option is supported only for standard card payments, and when it is used, the list of available currencies is shown to the customer only after the card number has been entered. - Selecting currency out of those relevant for the country where the card was issued \(determined by the card number\) or, if relevant currencies are not available, the option to choose the currency can be removed and the payment request currency can be used instead. For example, if the customer uses the card issued in Brazil, and the Brazilian real is not supported as an operational currency for the project in question, only the payment request currency can be shown for selection. This option is supported only for standard card payments, and when it is used, the list of available currencies is shown to the customer only after the card number has been entered. You can compile lists of available currencies for each project and can also decide on the option of filtering the available currencies for card payments. Thus, the list of available currencies can differ depending on the project, payment method, and payment instrument. - *Dollars, euros, or pounds sterling can be used as balance currencies.* If the customer selects to pay in euros, US dollars, or pounds sterling, and the payment is processed in the selected currency and the balances in the relevant currencies have been configured, the merchant receives the funds in this currency. In all other cases, the merchant receives the funds in US dollars. - *Currency conversion is performed with the use of exchange rates set by Ecommpay.* These rates are calculated by Ecommpay according to the market data provided by the speciliased partner services.To monitor payments with conversion, you can use different interfaces of the payment platform \([details](en_platform_payment_information_overview.md)\). You can also contact your account manager to learn more about exchange rates and the specifics of how they are applied. ## Workflow {#section_crb_rvt_whc .section} You do not need to update your web service to support payment currency selection by the customer\(as far as standard processing workflows for payments of a specific type are concerned\). The following is a workflow of a one-step purchase that requires conversion to the currency selected by the customer. ![](images/en_pp_uml_conversion.svg) 1. Payment Page sends to the payment platform the request to obtain informationabout available currencies and exchange rates required for currency conversion. 2. The payment platform processes the request. 3. The payment platform sends the information required for currency conversion to Payment Page. 4. Payment Page displays the list of available currencies. 5. The customer selects the currency and enters necessary details. 6. Payment Page sends to the payment platform the request for paymentdenominated in the currency that the customer selected. When the currency selected by the customer differs from the one specified in the payment request, payment result callbacks can contain \(if it has been configured\)the `sum_customer` object with the following parameters: - `amount`—the operation amount in the smallest units of the currency selected by the customer - `currency`—the code of the currency selected by the customer in ISO-4217 alpha-3 This information is used as complementary to the data about the amount and currency passed in the `operation` object: - `sum_initial`—the initial amount and currency of the request - `sum_converted`—the converted amount and currency that were actually used to perform the operation The following is an example of the payment with a conversion operation in which `10.00 USD` are converted into `57.60 BRL` as the customer selected to pay in `BRL`, and the amount the customer actually paid is equal to `57.60 BRL`. ```language-json { "payment":{ "method":"card", "sum":{ "amount":1000, // payment amount in the requested payment currency "currency":"USD" // code of the requested payment currency }, "id":"11006", "type":"purchase", "status":"success", "date":"2022-06-23T13:32:09+0000", "description":"" }, "customer":{ "id":"12" }, "sum_customer":{ "amount":5760, // amount in the customer selected currency "currency":"BRL" // code of the customer selected currency }, "account":{ "number":"541333******0019" }, "project_id":42, "operation":{ "created_date":"2022-06-23T13:32:02+0000", "request_id":"a23962a836e8e4-db4f1981d9-0006", "sum_initial":{ "amount":1000, // operation amount in the requested payment currency "currency":"USD" // code of the requested payment currency }, "sum_converted":{ "amount":5760, // operation amount in the actual operational currency "currency":"BRL" // code of the actual operational currency }, "code":"0", "message":"Success", "eci":"05", "provider":{ "id":6, "payment_id":"1629803", "auth_code":"563253", "endpoint_id":6, "date":"2022-06-23T10:32:09+0000" }, "id":682400942, "type":"sale", "status":"success", "date":"2022-06-23T13:32:09+0000" }, "signature":"BsGd0vcBQjd+aFl8ehEPRjf/eQUABow+VO+/xSG+lqKo6xHQ==" } ``` ## Setup {#section_fwh_jzt_whc .section} To set up the functionality of currency conversion when the customer chooses the currency: 1. With your Ecommpay account manager, discuss adding and setting up this functionality.Agree upon: - which projects, payment methods, and relevant currencies are required. - Whether you need the option to filter available currencies by the customer's card country. - Whether testing is necessary. 2. If you need testing, once you get notified by the Ecommpay specialists that the payment form is ready for being used in test mode, test this functionality, and inform Ecommpay that everything is ready to launch. 3. Get notified by the Ecommpay specialists that the functionality has been added and fully set up. **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Supporting sustainable payments {#en_pp_ekko_earth} An article about the capability of adding the option to payment form workflows that allows contributing to environmental projects via the ekko partner service. ## Overview {#section_fgl_3d1_1gc .section} When working via Payment Page, you can extend checkout scenarios by adding the option to make financial contributions to environmental projects via the specialised partner service of the [ekko](https://ekko.earth/) platform—right after the standard payment scenario steps have been completed. This capability empowers customers to make sustainable choices aimed at protecting the planet alongside their purchases and allows merchants to demonstrate their commitment to sustainability and generating positive environmental impact within their services. ![](images/ecommpay/en_pp_ekko_earth.svg "Including the carbon tracking option on the final page of the payment form") While using this capability does not require you to expend any additional technical effort or pay any extra fees, it allows you to participate in environmental initiatives and helps increase customer loyalty and brand value. ## Special aspects and limitations {#section_i25_xt1_1gc .section} When working with the sustainable payments capability, consider the following special aspects and limitations: - The functionality is supported only for the 5th generation Payment Page. - The functionality is available to customers at checkout if the initial payment is [a purchase](en_pp_purchase.md) or such action as [an authorisation hold](en_pp_purchase_auth.md) or [a registration of a COF payment](en_pp_recurring.md). - Customers can contribute to environmental initiatives using the payment methods supported both by Ecommpay and by the ekko service, regardless of which payment methods are available within the merchant’s project. Methods that can be used for sustainability payments include [standard card payments](en_pm_card_payments.md), [Apple Pay](pm_applepay.md#), and [Google Pay](pm_googlepay.md#). - Each contribution is processed as a separate payment—in the same currency used for the initial payment that was processed before the customer was redirected to the ekko service and outside the project through which the initial payment was made. This approach allows utilising the payment methods supported for sustainable payments and prevents merchant services from getting overloaded with additional data related to these contributions. - A sustainable payment is processed within a separate Payment Page session, with the payment form custom design by Ecommpay and ekko. In addition, the parameters of the project within which the initial payment was made do not apply to processing a subsequent contribution. - Customers receive notifications about processing of their contributions directly from the ekko service. If they have any questions about their sustainable payments, they can also be referred to ekko for more details. To learn more about the specifics of working with this functionality, contact your Ecommpay account manager. ## Processing scenario {#section_y54_zt1_1gc .section} Below is a user scenario of making a sustainable payment enabled by ekko via Payment Page. 1. On the final page of the payment form, alongside the confirmation that the initial payment or action has been completed successfully, an additional panel is displayed to the customer with the option to proceed to the ekko service in order to make a contribution. 2. The customer is redirected to the ekko service. 3. The customer selects the desired contribution amount and is redirected to the payment form \(a new Payment Page session is initiated\). 4. The customer is shown the payment form \(with custom design by Ecommpay and ekko\). 5. The customer selects the payment method, enters the required details, and confirms making a contribution. 6. The customer is shown the preloader page and then the payment complete page. 7. The customer is redirected to the ekko service page showing the contribution confirmation and offering the option to enter an email address for an additional receipt. 8. The customer receives a receipt at the provided email. As with other payment scenarios, making a sustainable payment may require additional procedures such as the 3‑D Secure authentication \([details](en_PP_Additional.md)\). However, execution of these procedures does not require the merchant's web service to perform any further actions outside of the already established scope. ## Setup {#section_qsp_251_1gc .section} To set up the functionality of sustainable payments: 1. With your Ecommpay account manager, discuss and agree upon setting up this functionality for specific projects and whether testing is necessary. 2. If you need testing, get notified by the Ecommpay specialists that the payment form is ready for being used in test mode, test this functionality, and inform Ecommpay that everything is ready to launch. 3. Get notified by the Ecommpay specialists that the functionality has been added and fully set up. **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Debt repayment {#en_PP_debt_repayments} An article about the capability of using the payment form to accept loan repayments. ## General information {#section_knc_3mq_4mb .section} *Debt repayment* is a type of purchase from the customer's card intended for payment of a loan or debt. This type of payment is available for merchants providing microfinance services with the category code `6012` or `6051`, and is also mandatory for MFIs that are registered in the United Kingdom \(for Mastercard payments\) or the European Union \(for Visa payments\). Debt repayment can be made as a one-time purchase, registration of a COF payment, or card verification operation. If an MFI is registered in the United Kingdom \(for Mastercard payments\) or in the European region according to Visa regulations \(for Visa payments\) in addition to the required objects and parameters, the MFI account number and additional customer data must be specified in the request: - debt\_account—the merchant account number for debiting funds from the customer's card in order to repay the debt. Latin letters and numbers are allowed, the maximum length is 10 characters - customer\_first\_name—first name - customer\_last\_name—last name - customer\_day\_of\_birth—date of birth, in the DD-MM-YYYY format - customer\_zip—postal address code \(mandatory for the UK\). This functionality is not available for payments with American Express cards. If the parameter is not specified in the request, a callback containing this parameter is sent for additional payment information submission \(for more details, see [Submission of additional payment information](en_pp_clarification.md)\). ```language-xml EPayWidget.run( { payment_id: '3936', payment_amount: 1000, payment_currency: 'EUR', project_id: 200, debt_repayment: '897896541, customer_first_name: 'John', customer_last_name: 'Johnson', customer_zip: 'SW1W 0NY, customer_day_of_birth: '12-05-1990', customer_id: '1', signature: "PJkV8ej\/UG0Di8NN5...==" } ) ``` If the debt repayment is made by the registration of a COF payment—you do not need to pass additional parameters in requests for payment processing—they will be taken from the initial request for registration. For more information about this functionality and how to enable it, refer to the Ecommpay key account manager. ## Mastercard restrictions {#section_jzh_kmq_4mb .section} According to Mastercard requirements, this functionality is available to merchants from the United Kingdom only with the category code `6012`. For all other countries both `6012` or `6051` codes are available. It is prohibited to repay debts from credit and prepaid cards if the country of issue of the card and registration of the merchant is the United Kingdom. ## Visa restrictions {#section_gb2_lmq_4mb .section} According to Visa requirements, merchants from the United Kingdom who accept payment of overdue debts must have the category code `6051`. In other cases and for all other countries both `6012` or `6051` codes are available. It is prohibited to repay debts from credit cards. **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Limiting time for working with payment form {#en_pp_time_limit} An article about the capability of setting the time limit for making a purchase within a single payment form invocation. ## Overview {#section_pk4_rgg_nmb .section} During the work with Payment Page, it is possible to specify the date and time until which the customer can work with the paymentformto confirm the targeted action. This capability allows to control providing services to customers with regard to time and can be especially relevant in sales of tickets or clearance sales of goods. The date and time allocated for working with the payment form are specified in requests for opening Payment Page, and for setting up this capability, there are no additional actions required. If the restriction is set, the Payment Page pages contain an additional information panel that displays: - the information about the time when the work with the form is set to be completed, in the format of `hh:mm`; - the information about the time that remains until the completion of the work with the form, with the use of the timer `mm:ss`; - the indicator that counts down the final five minutes of the whole time allocated for working with Payment Page. **Note:** Note that the time allocated for working with the form cannot exceed 30 days from the moment when the request for opening Payment Page was sent. Otherwise the date and time specified in the request will be ignored and the time limit will not be applied. ## Usage scenario {#section_ctr_ghg_nmb .section} On the customer side, purchase processing with the limited time of working with Payment Page looks as follows: 1. On the merchant web service side, the customer confirms the purchase of the order and is redirected to the payment form. 2. The customer performs the actions required for making the purchase and receives the result information. In case if the customer does not confirm the targeted action until the allocated time expires, the customer is notified about the time expiration on the next page of the payment form. ![](images/ecommpay/en_pp_time_limit_1.svg "1 — Opening payment form") ![](images/ecommpay/en_pp_time_limit_2.svg "2 a — Processing purchase") ![](images/ecommpay/en_pp_time_limit_3.svg "2 b — Declining purchase due to time expiration") ## Special aspects {#section_np3_qhq_5tb .section} When using the capability of limiting the time of the work with Payment Page, consider the following aspects: - During the processing of separate payments, payment systemsor providers can require additional customer data—this can increase the time of working with the form \([details](en_pp_clarification.md)\). - The time allocated for working with the form within a separate payment is also relevant for making all retry attempts within this payment, regardless of their number \([details](en_PP_Try_Again.md)\). ## Request format {#section_pnk_grg_nmb .section} To specify the time limit within which the customer can work with the form, pass the best\_before parameter with the date, time, and time zone in the format of `YYYY-MM-DDThh:mm:ss±hh` or `YYYY-MM-DDThh:mm:ss±hh:mm` in the request for opening Payment Page.The time allocated for working with the form cannot exceed 30 days from the moment when the request for opening Payment Page was sent. ```language-json { // required parameters for purchase processing "project_id": 42, "payment_id": "7654321777", "payment_currency": "USD", "payment_amount": 131970, "customer_id": "customer_12", "signature": "TSzdE5rJZaA9TYAKoGpfXriFf82MxF...", // date and time when the work with the payment form is set to be completed— // 12 April 2021 10:15:30, GMT+3 "best_before": "2021-04-12T10:15:30+03" } ``` **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Using dynamic merchant descriptor {#en_pp_descriptor} An article about the capability of providing customers with information about merchants via issuer services. ## Overview {#section_u2p_3rk_mhc .section} When Ecommpay acts as an acquirer, in compliance with the rules of card networksEcommpay shares merchant details with other parties involved in payment processing. These detailscan be used by each party at its discretion and can be specified in receipts and bank statements by issuers. By default, merchant information isstatic and limited toagreed upon name of the merchant. However, the merchant can dynamically append additional detailsrelating to a particular paymentor other aspects of their business . These dynamic details can be included in the requests for opening Payment Pageand are only limited to the maximum string length and the permitted character set \(see [details](en_pp_descriptor.md#section_b3f_hvp_13c)\). For example, the merchant descriptor can include the merchant's name combined with a booking period \(`Cosmotour* 17-19 feb`\) or with the name of the reserved hotel \(`Cosmotour* MarsSuite`\). ![](images/ecommpay/en_gate_descriptor_2.svg "Adding booking period") ![](images/ecommpay/en_gate_descriptor_1.svg "Adding hotel name") Flexible use of accurate and informative details makes it easier for customers to identify merchants and payments and allows merchants to improve user experience and reduce the risk of disputes.In the Ecommpay payment platform, dynamic descriptors are relevant for *card payments* \(including standard card payments and payments made with Apple Pay, Click to Pay, Google Pay, and Visa Instalments\) and such payment types as one-time and COF purchases, payouts, and payment instrument verification. ## Special aspects {#section_fhg_s3m_djc .section} When working with merchant data, consider the following special aspects: - The primary purpose of the merchant descriptor is to help customers recognise payments they made and prevent unnecessary chargebacks. Hence, avoid ambiguous or potentially misleading information in the merchant descriptor. Focus on the information that enables the customer to identify both the merchant and each operation clearly. In particular, it is recommended that you use a familiar brand name together with a concise description of the goods or services related to the operation. - Requirements to the merchant descriptor can vary depending on the card network. Pay attention to such differences, at least regarding the supported formats \([details](en_pp_descriptor.md#section_b3f_hvp_13c)\). - The way merchant details are provided to users is determined by issuers. How merchant details will appear in receipts, bank statements, and other communication with the customer is determined by the rules of a specific issuer. As a result, merchant details may vary across issuers, different interfaces of the same issuer, and different operation types within a single interface. In particular, there may be differences due to processing different types of purchases ans payouts as well as Mastercard MoneySend and Visa Direct operations. ## Setup {#section_umd_gyr_djc .section} The name of the merchant to be used as a default merchant descriptor is specified when the merchant is onboarded with the payment platform and, subsequently, can only be modified via the Ecommpay account manager. To enable the use of the dynamic merchant descriptor, continue as follows: 1. Coordinate with the Ecommpay account manager the roadmap of enabling the functionalityfor specific projects and the necessity for testing.. 2. If you need testing, get notified by the Ecommpay specialists that the capability is ready for being used in test mode,test this capability, and inform Ecommpay that everything is ready to launch. 3. Get notified by the Ecommpay specialists that the capability has been added and fullyset up. ## Use {#section_okm_gyr_djc .section} If you need to use the dynamic merchant descriptor, pass the corresponding parameter in the requests for opening Payment Page: - `merchant_descriptor` for purchases and payment instrument verification - `sender_descriptor` for payouts Keep in mind that in cases when the values of the `merchant_descriptor` and `sender_descriptor` parameters do not conform to the required format \([details](en_pp_descriptor.md#section_b3f_hvp_13c)\), the platform can automatically correct them\(for example, by transliterating alphabetic characters and removing invalid non-alphabetic characters\). Such correction of values does not lead to declined payments. Also, note that the Ecommpay platform does not validatethe values of these parametersfor factual correctness, but this information can be analysed and subsequently used by the issuers. Merchants should therefore ensure that values provided in the `merchant_descriptor` and `sender_descriptor` parameters are both technically compliant and contextually accurate in every instance of use. ## Data format {#section_b3f_hvp_13c .section} The maximum length of the merchant descriptor is determined by the card network. Mastercard sets a maximum length of 22 characters, while Visa sets a maximum length of 25 characters.Any characters exceeding these limits are truncated. Keep these limits and the allowed character requirements in mind when generating descriptions. The `merchant_descriptor` and `sender_descriptor` parameters can contain characters from the basic Latin alphabet, digits, a space character \(U+0020\) and the following symbols: |`*`|U+002A|asterisk| |`,`|U+002C|comma| |`-`|U+002D|hyphen| |`.`|U+002E|full stop| |`=`|U+003D|equals sign| |`_`|U+005F|underscore| When generating the `merchant_descriptor` or the `sender_descriptor` parameter, use the agreed uponmerchant's name followed by additional details separated by an asterisk \(`*`\) and a space, ensuring compliance with the applicable string length restrictions. For example, if a 9-character name `Cosmotour` is used with a 2-character separator, the remaining string length available for additional details is 11 characters for Mastercard and 14 characters for Visa. This is enough for a value such as `Cosmotour* to the Moon`. **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Sending receipts and notifications to customer {#en_PP_receipt_data .concept} An article about the capability of informing customers about payment processing and related events via email notifications. ## Sending a receipt {#section_nkg_4ln_lhb .section} If you need to send sales receipts to customers, you have to make sure that this functionality is enabled in the settings. You also have to make sure that all positions to be indicated in the receipt are passed in the payment request. When this functionality is added and configured, you can also decide on the set of languages available for forming receipts and choose the default language. In individual cases, a different language can be selected the same way as the language of the payment form—with the use of the `language_code` parameter. The data for the receipt is passed as a JSON object which is encoded in Base64 and sent in the payment request in the receipt\_data parameter. The JSON object structure is given in the `[receiptdata](https://api-developers.ecommpay.com/api.html#/c2NoOjQwNTY3ODY2-receipt-data)` model in the Gate API. ## Example of the receipt data to be sent {#section_l5c_lft_lhb .section} Initial JSON object: ```language-json { "receipt_data":{ "positions":[ { "quantity":3, "amount":10000, "tax":18, "tax_amount":1800, "description":"Design frame" } ], "total_tax_amount":1800, "common_tax":18 } } ``` The same data, encoded in Base64, to be sent to Payment Page in the payment request \(the contents of the parameter are split into several lines for the reader's convenience\): ``` receipt_data: "eyAgCiAgICAgICJwb3NpdGlvbnMiOlsgIAogICAgICAgICB7ICAKICAgICAg ICAgICAgInF1YW50aXR5IjozLAogICAgICAgICAgICAiYW1vdW50IjoxMDAwMCwKICAgICAgICAgICAgInRheCI 6MTgsCiAgICAgICAgICAgICJ0YXhfYW1vdW50IjoxODAwLAogICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJEZXN pZ24gZnJhbWUiCiAgICAgICAgIH0KICAgICAgXSwKICAgICAgInRvdGFsX3RheF9hbW91bnQiOjE4MDAsCiAgICA gICJjb21tb25fdGF4IjoxOCAgICAgICAKfQ" ``` For more information about sending receipts to customers, see the section [Sending notifications to customers](en_gate_receipts.md#). **Parent topic:**[Auxiliary procedures and additional capabilities](en_PP_Additional.md) --- # Payment Page API specification {#en_PP_Parameters} An API specification with the description of data structures used in requests for opening Payment Page. This article describes parameters used to open Payment Page, including basic information about them and links to related articles, which contain descriptions of the parameters' functionality and set out possible scenarios for their use. Parameters marked in this list as required must be included in all Payment Page callsintended to process payments. In the Card Tokenize mode, the following parameters are *not* required: `payment_amount`, `payment_currency`, `payment_id`. Parameters marked in this list as optional can be used as additional parameters for specific projects and payment methods.Moreover, the inclusion of some parameters is recommended in order to avoid the customer being subjected to the 3‑D Secure authentication procedure \(i.e., undergo authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\) and having to provide [additional payment information](en_pp_clarification.md), as well as for other improvements to custom scenarios and the general functionality of the payment form. If you have any additional questions about whether specific parameters are required or recommended for different individual use cases, consult the existing documentation and the Ecommpay technical support specialists. |Parameter|Description| |---------|-----------| |`account_token` string, optional |Payment instrument token. Consists of an identifier obtained for a specific payment instrument from the payment platform when data for that instrument is saved. Can be used to perform payments using that saved data \(i.e., when [making a purchase](en_PP_Payment_by_token.md)\). Example: `42ab631449a78914502803aed8a0e5a728d558035d29a56f4dcc136c6bfc3021` | |`avs_post_code` string, optional |The postal code of the customer to be used in the [Address Verification Service](en_PP_avs.md) check. Example: `WS13 6LG` | |`avs_street_address` string, optional |The address of the customer to be used in the [Address Verification Service](en_PP_avs.md) check. Consists of a house number and a street name. Example: `4 Breadmarket Street` | |`baseUrl` string, optional |The base URL used to open the payment form. Must be specified whena root address different from the default one \(https://paymentpage.ecommpay.com\) has been approved by the Ecommpay account manager, in cases where the address needs to be provided explicitly. Example: `https://cosmopage.site.com` | |`best_before` string, optional |The date and time in the specified timezone until which the customer is able to use the payment form to confirm their targeted action \(see [this article](en_pp_time_limit.md)\). Should be specified as follows: `YYYY-MM-DDThh:mm:ss`±`hh` or `YYYY-MM-DDThh:mm:ss`±`hh:mm`. The time allocated for working with the form cannot exceed 30 days from the moment when the request for opening Payment Page was sent. Example: `2024-04-26T13:50:37+00` | |`billing_address` string, optional |The house number\(including any additional parts of the address such as building indicators and apartment numbers\) andthe name of the street in the customer's billing address. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). Example: `33 Store Street` | |`billing_city` string, optional |The name of the city in the customer's billing address. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). Example: `London` | |`billing_country` string, optional |The country code in the customer's billing address. Specified in the ISO 3166-1 alpha-2 format. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). Pattern: `^[A-Z]{2}$`. Example: `GB` | |`billing_postal` string, optional |The postal code in the customer's billing address. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). Example: `BR1 1AA` | |`billing_region` string, optional |The name of the region\(i.e., state, province, or other administrative division type\) in the customer's billing address. When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). Example: `Greater London` | |`billing_region_code` string, optional |The recipient's country subdivision code \(state, province, region, or territory\). The value of this parameter is the second element of a code for a subdivision \(in ISO 3166-2\), without the two-letter country code and the hyphen-minus used as a separator. This parameter should be specified in requests where the `billing_country` parameter is also specified.When the parameter is passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). Pattern: `^[0-9A-Z]{1,3}$`. Example: `DOR` | |`booking_info` string, optional |Booking information tracked by the web service. Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme.The JSON object can include various combinations of elements from the list of supported data. Can be used to record and track relevant data about payments rendered for services by various organisations \(see [this article](en_pp_additional_data.md#)\). - `bookers`, array—the array with the information about the customers for whom the service is booked. Each element of this array contains: - `first_name`, string—the name of the customer provided at the time of booking - `last_name`, string—the last name of the customer provided at the time of booking - `email`, string—the email provided at the time of booking - `items`, array—the array with the information about separate services included in the booking. Each element of this array contains: - `description`, string—description of the service included in the booking - `start_date`, string, `^\\d{2}-\\d{2}-\\d{4}$`—starting date of the service included in the booking - `end_date`, string, `^\\d{2}-\\d{2}-\\d{4}$`—ending date of the service included in the booking - `start_date`, string, `^\\d{2}-\\d{2}-\\d{4}$`—starting date of the booked service - `end_date`, string, `^\\d{2}-\\d{2}-\\d{4}$`—ending date of the booked service - `description`, string—a free-form description of the booked service - `total`, integer—the total cost of the booking - `pax`, integer—the number of people per booking - `reference`, string—the booking reference, which can be the URL, the name of the booked service, or its code in the merchant web service - `id`, string—the identifier of the booking, unique in the merchant web service ``` {#codeblock_t2l_mzm_phc .language-json} "booking_info": { "start_date": "12-08-2026", "end_date": "14-08-2026", "description": "Sideris music festival full pass", "total": 200000, "pax": 2, "bookers": [ { "first_name": "William", "last_name": "Herschel", "email": "rsfellow@mail.com" }, { "first_name": "Caroline", "last_name": "Herschel", "email": "salariedastronomer@mail.com" } ], "items":[ { "description": "VIP Arrival", "start_date": "12-08-2026", "end_date": "12-08-2026" }, { "description": "Hotel", "start_date": "12-08-2026", "end_date": "14-08-2026" }, { "description": "Concerts", "start_date": "12-08-2026", "end_date": "14-08-2026" }, { "description": "VIP Departure", "start_date": "14-08-2026", "end_date": "14-08-2026" } ], "reference": "musicfestlink", "id": "83" } ``` ``` {#codeblock_gt2_yzm_phc} ewogICJzdGFydF9kYXRlIjogIjEyLTA4LTIwMjYiLAogICJlbmRfZGF0ZSI6ICIxNC0wOC0yMDI2IiwKICAiZGVzY3JpcHRpb24iOiAiU2lkZXJpcyBtdXNpYyBmZXN0aXZhbCBmdWxsIHBhc3MiLAogICJ0b3RhbCI6IDIwMDAwMCwKICAicGF4IjogMiwKICAiYm9va2VycyI6IFsKICAgICB7CiAgICAgICAgImZpcnN0X25hbWUiOiAiV2lsbGlhbSIsCiAgICAgICAgImxhc3RfbmFtZSI6ICJIZXJzY2hlbCIsCiAgICAgICAgImVtYWlsIjogInJzZmVsbG93QG1haWwuY29tIgogICAgIH0sCiAgICAgewogICAgICAgICJmaXJzdF9uYW1lIjogIkNhcm9saW5lIiwKICAgICAgICAibGFzdF9uYW1lIjogIkhlcnNjaGVsIiwKICAgICAgICAiZW1haWwiOiAic2FsYXJpZWRhc3Ryb25vbWVyQG1haWwuY29tIgogICAgIH0KICBdLCAgICAgICAgCiAgIml0ZW1zIjpbCiAgICAgewogICAgICAgICJkZXNjcmlwdGlvbiI6ICJWSVAgQXJyaXZhbCIsCiAgICAgICAgInN0YXJ0X2RhdGUiOiAiMTItMDgtMjAyNiIsCiAgICAgICAgImVuZF9kYXRlIjogIjEyLTA4LTIwMjYiCiAgICAgfSwKICAgICB7CiAgICAgICAgImRlc2NyaXB0aW9uIjogIkhvdGVsIiwKICAgICAgICAic3RhcnRfZGF0ZSI6ICIxMi0wOC0yMDI2IiwKICAgICAgICAiZW5kX2RhdGUiOiAiMTQtMDgtMjAyNiIKICAgICB9LAogICAgIHsKICAgICAgICAiZGVzY3JpcHRpb24iOiAiQ29uY2VydHMiLAogICAgICAgICJzdGFydF9kYXRlIjogIjEyLTA4LTIwMjYiLAogICAgICAgICJlbmRfZGF0ZSI6ICIxNC0wOC0yMDI2IgogICAgIH0sCiAgICAgewogICAgICAgICJkZXNjcmlwdGlvbiI6ICJWSVAgRGVwYXJ0dXJlIiwKICAgICAgICAic3RhcnRfZGF0ZSI6ICIxNC0wOC0yMDI2IiwKICAgICAgICAiZW5kX2RhdGUiOiAiMTQtMDgtMjAyNiIKICAgICB9CiAgXSwKICAicmVmZXJlbmNlIjogIm11c2ljZmVzdGxpbmsiLAogICJpZCI6ICI4MyIKfQ== ``` | |`card_holder` string, optional |The first and last name of the payment card holder. Data specified in this parameter can be used to fill in the corresponding fields on the payment form in advance—this data can then still be edited by the customer—and should be spelled as specified on the card and adhere to the rules for specifying names \(see [this article](en_faq_payment_processing.md#section_dbx_kby_t1c)\). Pattern: `^[\p\{L}\p\{M}\s\-\'.]{1,255}$`. Example: `John Doe` | |`close_on_missclick` integer \(boolean\*\), optional |Indicator that specifies the action to be taken if the customer clicks outside of the borders of a payment form opened in a [modal window](en_PP_method_ModalWindow.md#). Should be specified for calls that make use of a modal window. Can have one of the following values: - `0`—do not close the payment form \(used by default\), - `1`—close the form. If the `merchant.js` library is used \([details](en_pp_interaction_organisation.md#)\), this parameter can be specified as a boolean value and set to either `false` or `true`. Example: `1` | |`css_modal_wrap` string, optional |Indicator for an additional CSS class to wrap the payment form inside of a modal window. Should be specified for calls that make use of a modal window. Example: `CosmoshopModal` | |`customer_address` string, optional |The name of the street and the house number\(including any additional parts of the address such as building indicators and apartment numbers\) in the customer's address, separated by a comma. The length of the string cannot be more than 255 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `Main Street, 12` | |`customer_account_info` string, optional |Information about the customer's account and contact detailsobtained by the web service. Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme.The JSON object can include the `customer` object containing various combinations of elements from the list of supported data. When passed for card purchases, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). - `address_match`, string—indicates whether the customer's billing address matches the address specified in the `shipping` object: - `Y`—addresses match - `N`—addresses do not match - `home_phone`, string—the customer's home phone number, contains between 4 and 24 digits - `work_phone`, string—the customer's work phone number, contains between 4 and 24 digits - `account`, object—the object with the customer's account information kept on file by the merchant: - `activity_day`, integer—number of payment attempts in the last 24 hours, 3 characters maximum - `activity_year`, integer—number of payment attempts in the last 365 days, 3 characters maximum - `additional`, string—additional information about the customer's account in free text, for example, its identifier. Can contain up to 64 characters - `age_indicator`, string, `^0[1-5]$`—number of days since the customer account was created. Possible values: - `01`—guest checkout - `02`—the account was created at the moment of making a payment - `03`—fewer than 30 days - `04`—between 30 and 60 days - `05`—more than 60 days - `auth_data`, string—additional login information in free text, can contain up to 255 characters - `auth_method`, string, `^(0[1-4]|0[1-4][1-6])$`—indicates how the customer was authenticated during their most recent login to the web service. Can have one of the possible values: - for standard card payments: - `01`—no authentication - `02`—logging in with authentication data kept on file by the merchant - `03`—logging in with the federated identity credentials \(for example, Google Account or Facebook ID\) - `04`—logging in with the use of FIDO authenticator \(Fast Identity Online\) - `auth_time`, string, `^\\d{2}-\\d{2}-\\d{4}\\d{2}:\\d{2}$`—date and time of the customer's most recent account login in the `DD-MM-YYYYhh:mm` format - `change_date`, string, `^\\d{2}-\\d{2}-\\d{4}$`—date of the most recent change to the account, except for the password change or password reset, in the `DD-MM-YYYY` format - `change_indicator`, string, `^0[1-4]$`—number of days since the most recent change to the account, except for the password change or password reset. Possible values: - `01`—the account was updated on the day when the payment was made - `02`—fewer than 30 days - `03`—between 30 and 60 days - `04`—more than 60 days - `date`, string, `^\\d{2}-\\d{2}-\\d{4}$`—the account creation date in the `DD-MM-YYYY` format - `pass_change_date`, string, `^\\d{2}-\\d{2}-\\d{4}$`—date of the most recent password change or reset in the `DD-MM-YYYY` format - `pass_change_indicator`, string, `^0[1-5]$`—number of days since the most recent password change or reset. Possible values: - `01`—password was not changed or reset - `02`—password was changed or reset on the day when the payment was made - `03`—fewer than 30 days - `04`—between 30 and 60 days - `05`—more than 60 days - `payment_age`, string, `^\\d{2}-\\d{2}-\\d{4}$`—card record creation date in the `DD-MM-YYYY` format - `payment_age_indicator`, string, `^0[1-5]$`—number of days since the payment card details were saved to a customer's account. Possible values: - `01`—guest checkout - `02`—card details were saved on the day when the payment was made - `03`—fewer than 30 days - `04`—between 30 and 60 days - `05`—more than 60 days - `provision_attempts`, integer—number of attempts to save new card details to a customer's account in the last 24 hours, 3 characters maximum - `purchase_number`,—number of purchases made via the customer's account in the last 6 months, 4 characters maximum - `suspicious_activity`, string, `^0[1-2]$`— indicates the presence of suspicious activity. Possible values: - `01`—no suspicious activity detected - `02`—suspicious activity detected ```language-json { "customer":{ "address_match":"Y", "home_phone":"442055526608", "work_phone":"442055537709", "account":{ "additional":"gamer12345", "age_indicator":"01", "date":"01-10-2022", "change_indicator":"01", "change_date":"01-10-2022", "pass_change_indicator":"01", "pass_change_date":"01-10-2022", "purchase_number":12, "provision_attempts":16, "activity_day":22, "activity_year":222, "payment_age_indicator":"01", "payment_age":"01-10-2022", "suspicious_activity":"01", "auth_method":"01", "auth_time":"01-10-202213:12", "auth_data":"login_0102" } } } ``` ``` eyAKICAiY3VzdG9tZXIiOnsgCiAgICAiYWRkcmVzc19tYXRjaCI6IlkiLAogICAgImhvbWVfcGhvbmUiOiI0NDIwNTU1MjY2MDgiLAogICAgIndvcmtfcGhvbmUiOiI0NDIwNTU1Mzc3MDkiLAogICAgImFjY291bnQiOnsgCiAgICAgICJhZGRpdGlvbmFsIjoiZ2FtZXIxMjM0NSIsCiAgICAgICJhZ2VfaW5kaWNhdG9yIjoiMDEiLAogICAgICAiZGF0ZSI6IjAxLTEwLTIwMjIiLAogICAgICAiY2hhbmdlX2luZGljYXRvciI6IjAxIiwKICAgICAgImNoYW5nZV9kYXRlIjoiMDEtMTAtMjAyMiIsCiAgICAgICJwYXNzX2NoYW5nZV9pbmRpY2F0b3IiOiIwMSIsCiAgICAgICJwYXNzX2NoYW5nZV9kYXRlIjoiMDEtMTAtMjAyMiIsCiAgICAgICJwdXJjaGFzZV9udW1iZXIiOjEyLAogICAgICAicHJvdmlzaW9uX2F0dGVtcHRzIjoxNiwKICAgICAgImFjdGl2aXR5X2RheSI6MjIsCiAgICAgICJhY3Rpdml0eV95ZWFyIjoyMjIyLAogICAgICAicGF5bWVudF9hZ2VfaW5kaWNhdG9yIjoiMDEiLAogICAgICAicGF5bWVudF9hZ2UiOiIwMS0xMC0yMDIyIiwKICAgICAgInN1c3BpY2lvdXNfYWN0aXZpdHkiOiIwMSIsCiAgICAgICJhdXRoX21ldGhvZCI6IjAxIiwKICAgICAgImF1dGhfdGltZSI6IjAxLTEwLTIwMjIxMzoxMiIsCiAgICAgICJhdXRoX2RhdGEiOiJsb2dpbl8wMTAyIgogICAgfQogIH0KfQ===== ``` | |`customer_account_number` string, optional |The identifier assigned to the customer's account by the payment system. May be required when using specific payment methods\(e.g., [Neteller](pm_neteller.md#) and [OVO Wallet](pm_ovo.md#)\). Depending on the particular method, may consist of an e-wallet identifier, an email address, a phone number, or a different kind of identifier. Example: `example@mail.com` | |`customer_birthplace` string, optional |The name of the customer's birthplace\(e.g., town, city, or other settlement type\). The length of the string cannot be more than 255 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `London` | |`customer_city` string, optional |The name of the place of residence \(e.g., town, city, or other settlement type\) in the customer's address. The length of the string cannot be more than 255 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `London` | |`customer_country` string, optional |The country code in the customer's address. Specified in ISO 3166-1 alpha-2 format.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Pattern: `^[A-Z]{2}$`. Example: `GB` | |`customer_day_of_birth` string, optional |The date of birth of the customer. Consists of a string specified in `DD-MM-YYYY` format.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Pattern: `^\\d{2}-\\d{2}-\\d{4}$`. Example: `12-12-1990` | |`customer_email` string, optional |The email address of the customer. The length of the string cannot be more than 255 characters. The string consists of a local-part and a domain name, separated by the "@" symbol. Required for purchases made using a payment card if the `customer_phone` parameter is not specified and the customer is not provided an opportunity to specify their phone number themselves \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `helen@example.com` | |`customer_first_name` string, optional |The first name of the customer. The length of the string cannot be more than 255 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `Jane` | |`customer_id` string, required |The identifier assigned to the customer within the scope of the project\(specified in `project_id`\). Each web service account should be linked to only one identifier and vice versa. This requirement is intended to address various risks and fraudulent operations. Example: `customer_112` | |`customer_last_name` string, optional |The last name of the customer. The length of the string cannot be more than 255 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `Smith` | |`customer_middle_name` string, optional |The middle, second, or patronymic name of the customer. The length of the string cannot be more than 255 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `Mary` | |`customer_mpi_result` string, optional |Information about the customer's most recent authentication via the 3‑D Secure protocol. Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme.The JSON object can include various combinations of elements from the list of supported data. When passed for card purchases, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). - `mpi_result`, object—object that contains information about the previous authentication attempt of the customer: - `acs_operation_id`, string, `^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$`—the identifier that the issuer assigned to the previous operation of the customer and returned in the `acs_operation_id` parameter of the callback with payment processing result. Can contain up to 36 characters. - `authentication_flow`, string, `^0[1-2]$`—the flow used by the issuer to authenticate the cardholder when processing the previous operation. It is a value of the `authentication_flow` parameter returned in the callback with payment processing result. Possible values: - `01`—frictionless flow - `02`—challenge flow - `authentication_timestamp`, string, `^\\d{12}$`—date and time of the previous successful customer authentication as returned in the `mpi_timestamp` parameter of the callback with payment processing result. ```language-json { "customer":{ "mpi_result":{ "acs_operation_id":"00000000-0005-5a5a-8000-016d3ea31d54", "authentication_flow":"01", "authentication_timestamp":"202210111050" } } } ``` ``` eyAKICAiY3VzdG9tZXIiOnsgCiAgICAibXBpX3Jlc3VsdCI6eyAKICAgICAgImFjc19vcGVyYXRpb25faWQiOiIwMDAwMDAwMC0wMDA1LTVhNWEtODAwMC0wMTZkM2VhMzFkNTQiLAogICAgICAiYXV0aGVudGljYXRpb25fZmxvdyI6IjAxIiwKICAgICAgImF1dGhlbnRpY2F0aW9uX3RpbWVzdGFtcCI6IjIwMjIxMDEwMTA1MCIKICAgIH0KICB9Cn0=== ``` | |`customer_phone` string, optional |The phone number of the customer. Generally, should include the country code; however, some cases do not require a country code to be specified. Should contain between four and 24 digits. If a particular project and payment method allow for the inclusion of punctuation marks and special characters in the phone number, the parameter can contain such characters in those cases; this is usually specially arranged beforehand.Required for purchases made using a payment card if the `customer_email` parameter is not specified and the customer is not provided an opportunity to specify their email address themselves \(see [this article](en_PP_Gathering_customer_data.md)\). Pattern: `^[0-9]{4,24}$`. Example: `443031237300` | |`customer_security_code` string, optional |The customer's purchase confirmation code. Some payment methods may require this parameter\(depending on the methods themselves\). Example: `852923` | |`customer_shipping` string, optional |Information about the delivery of a product or a service rendered to the customer. Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme.The JSON object can include various combinations of elements from the list of supported data. When passed for card purchases, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). - `shipping`, object—object with shipping details: - `address`, string—shipping address, can contain up to 150 characters. - `address_usage`, string, `^\\d{2}-\\d{2}-\\d{4}$`—date when the specified shipping address was used for the first time, in the `DD-MM-YYYY` format. - `address_usage_indicator`, string, `^0[1-4]$`—number of days since the specified shipping address was used for the first time. Possible value: - `01`—first-time use - `02`—fewer than 30 days - `03`—between 30 and 60 days - `04`—more than 60 days - `city`, string—shipping city, can contain up to 50 characters. - `country`, string, `^[A-Z]{2}$`—shipping country code in the ISO 3166-1 alpha-2 format. - `delivery_email`, string—the email to deliver purchased digital content to if the customer chooses email delivery. Can contain up to 255 characters. - `delivery_time`, string, `^0[1-4]$`—delivery time. Possible values: - `01`—digital same day delivery - `02`—same day delivery - `03`—next day delivery - `04`—delivery more than one day after the purchase was made - `name_indicator`, string, `^0[1-2]$`—indicates whether the customer's name matches the recipient's name. Possible values: - `01`—names match - `02`—names do not match - `postal`, string—shipping postal code, can contain up to 16 characters. - `region`, string—the name of the region \(state, province, or other administrative subdivision type\) of the shipping address. Can contain up to 255 characters. - `region_code`, string, `^[0-9A-Z]{1,3}$`—state, province, or region code in the ISO 3166-2 format, for example, `DOR` for Dorset. If you specify this parameter, you also need to specify and populate the `country` parameter in the `shipping` object. - `type`, string, `^0[1-7]$`—delivery option selected by the customer. Possible values: - `01`—delivery to the cardholder's billing address - `02`—delivery to a different verified address - `03`—delivery to the address that is not verified and does not match the billing address - `04`—store delivery - `05`—digital delivery - `06`—no delivery needed \(for example, event ticket purchase\) - `07`—other ```language-json { "customer":{ "shipping":{ "type":"01", "delivery_time":"01", "delivery_email":"test@gmail.com", "address_usage_indicator":"01", "address_usage":"01-10-2022", "city":"London", "country":"GB", "address":"Blackheath Ave", "postal":"SE10 8XJ", "region":"Vilnius County", "region_code":"LND", "name_indicator":"01" } } } ``` ``` eyAKICAiY3VzdG9tZXIiOnsgCiAgICAic2hpcHBpbmciOnsgCiAgICAgICJ0eXBlIjoiMDEiLAogICAgICAiZGVsaXZlcnlfdGltZSI6IjAxIiwKICAgICAgImRlbGl2ZXJ5X2VtYWlsIjoidGVzdEBnbWFpbC5jb20iLAogICAgICAiYWRkcmVzc191c2FnZV9pbmRpY2F0b3IiOiIwMSIsCiAgICAgICJhZGRyZXNzX3VzYWdlIjoiMDEtMTAtMjAyMiIsCiAgICAgICJjaXR5IjoiTG9uZG9uIiwKICAgICAgImNvdW50cnkiOiJHQiIsCiAgICAgICJhZGRyZXNzIjoiQmxhY2toZWF0aCBBdmUiLAogICAgICAicG9zdGFsIjoiU0UxMCA4WEoiLAogICAgICAicmVnaW9uX2NvZGUiOiJMTkQiLAogICAgICAibmFtZV9pbmRpY2F0b3IiOiIwMSIKICAgIH0KICB9Cn0== ``` | |`customer_ssn` integer, optional |The last four digits of the social security number of a US citizen. Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `1984` | |`customer_state` string, optional |The name of the region\(state, province, or other administrative subdivision type\) of the customer's address. The length of the string cannot be more than 255 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `Greater London` | |`customer_street` string, optional |The name of the street in the customer's address. The length of the string cannot be more than 255 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `Main` | |`customer_zip` string, optional |The postal or zip code in the customer's address. The length of the string cannot be more than 10 characters.Passing this information, along with other information about the customer, may help avoid having to provide additional information about the payment and simplify user scenarios \(see [this article](en_PP_Gathering_customer_data.md)\). Example: `75001` | |`debt_account` string, optional |The number of the account designated to receive funds as part of debt settlement purchases. This parameter is required for debt settlement purchases \(see [this article](en_PP_debt_repayments.md)\).The length of the string cannot be more than ten characters. Only Latin-script letters and digits are allowed. Example: `an9876170i` | |`force_acs_new_window` integer \(boolean\*\), optional |Indicator specifying whether a third-party web service that the customer is redirected to is opened in a new tab or not \(see [this article](en_PP_pm_redirect_mode.md)\). May be required for specific payment methods and can have one of the following values: - `0`—redirected using the mode specified as the default mode for the payment method, - `1`—redirected in a new tab, ignoring the mode specified as the default mode for the payment method. If the `merchant.js` library is used \([details](en_pp_interaction_organisation.md#)\), this parameter can be specified as a boolean value and set to either `false` or `true`. Example: `1` | |`force_payment_method` string, optional |The code of the payment method that should be preselected for the payment \(see [this article](en_PP__PreselectingPS.md)\). Can have values specified in the [payment method code list](en_pm_codes.md). Example: `paypal-wallet` | |`force_payment_group` string, optional |The code of the payment method group that should be preselected for the payment \(see [this article](en_PP__PreselectingPS.md)\). If this parameter is passed, only those payment methods that are part of the corresponding method group and are supported within the project will be available to the customer. However, if this parameter is passed together with the `force_payment_method` parameter, only the payment method linked to the code specified in that parameter will be preselected in the payment form, while the payment method group code will be ignored. Currently, this parameter can be used to preselect the Open Banking method group when you work with the 4th generation Payment Page—to do so, specify `openbanking` as the value. Example: `openbanking` | |`force_payment_method_subtype` string, optional |The code of the payment card brand that should be preselected for the payment \(see [this aticle](en_PP__PreselectingPS.md)\). Can have values specified in the [payment card code list](en_card_codes.md). Example: `mastercard` | |`hide` string, optional |A single code or a list of codes for payment methods that should be excluded from the payment form for the payment \([details](en_pp_methods_availability.md#)\). If a list of codes is specified, they should be separated by commas. Can have values specified in the [payment method code list](en_pm_codes.md). Example: `card, cup-union` | |`identify_doc_number` string, optional |The identifier of the document serving as a proof of identity for the customer. May be required for specific payment methods and can consist of a personal identity number, a taxpayer number\(e.g., [PIX](pm_pix.md#)\), or other similar identifiers. Example: `6543234567` | |`interface_type` string, optional |An identifier for the interface of the payment platform. Using this parameter requires case-by-case coordination with Ecommpay. Example: `{"id":7}` | |`language_code` string, optional |The code of the language in which the payment form should be displayed \(see [this article](en_PP_WigetLanguages.md#section_ivb_h3b_sqb)\) and the notifications should be generated \(see [this article](en_PP_receipt_data.md)\). Can consist of a two-letter ISO 639-1 alpha-2 code \(see [Language codes](en_language_codes.md)\) or a code in a different format when this has been arranged prior. Pattern: `/^([a-z]{2}|zh\-hant)$/i`. Example: `de` | |`merchant_callback_url` string, optional |URL for handling request callbacks. This parameter should be passed when callbacks for a request need to be sent to an address that is different from that specified by default \(for information about callbacks and how to use them, see [this article](en_platform_callbacks.md#)\). Example: `https://cosmoshop.earth/specialorder` | |`merchant_data` string, optional |Additional information that needs to be tracked by the web service. The data that is passed in this parameter can vary. However, what data set is passed in this parameter should be communicated to the Ecommpay specialists and configured beforehand to ensure the data is processed and displayed correctly in callbacks and payment information tabs \(see [this article](en_pp_additional_data.md#)\). In specific cases can contain a JSON object; then, the `"` character \(quotation mark, U+0022\) needs to be preceded by the `\` escape character \(reverse solidus, U+005C\) in order to be sent via a POST request. If the JSON object is passed via a GET request, escape characters are not required. ``` {#codeblock_jjf_xhb_d2c .language-json} "merchant_data": "{"items":[{"sku":"GM12-CC", "description":"10 Copper Coins","count":1}, {"sku":"GM12-GC","description":"Golden Coin", "count":2}],"total_count":3,"user_id":"122"}" ``` ``` {#codeblock_ts4_xhb_d2c .language-json} "merchant_data": "{\"items\":[{\"sku\":\"GM12-CC\", \"description\":\"10 Copper Coins\",\"count\":1}, {\"sku\":\"GM12-GC\",\"description\":\"Golden Coin\", \"count\":2}],\"total_count\":3,\"user_id\":\"122\"}" ``` | |`merchant_descriptor` string, optional |Information about the merchant provided to other parties involved in card payment processing and subsequently to customers. Can be used for processing purchases and performing payment instrument verification. The length of the string is limited to 22 characters for cards of the Mastercard card network and 25 characters for cards of the Visa card network. For more information on working with this parameter, see [this article](en_pp_descriptor.md). Example: `Cosmotour* to the Moon` | |`merchant_domain` string, optional |The domain name of the web service where the payment form should be opened. This parameter should be passed when Payment Page is invoked in the form of embedded Apple Pay and Google Pay payment buttons \(see [this article](en_pp_embedded_payment_buttons.md#)\). Example: `merchant.example.com` | |`merchant_fail_enabled` integer, optional |Indicator that specifies the availability options for the final redirection of the customer to the web service when a purchase is declined. Can have one of the following values: - `0`—redirectionto the web service is not available, - `1`—redirectionto the web service is available if Payment Page is opened in a separate browser tab\(in this case, how the web service page is opened is determined by the corresponding parameter from the `mode` group\) and not as an iframe object or in a modal window, - `2`—redirectionto the web service is available by default, using the mode specified in the `mode` parameter group. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `2` | |`merchant_fail_redirect_mode` string, optional |Indicator that specifies the mode for the final redirection of the customer to the web service when a purchase is declined. Can have one of the following values: - `iframe`—opens the pagein an iframe object \(this value is ignored if the payment form is opened in a new tab and the customer is redirected in that new tab\), - `parent_page`—opens the pagein the currently active tab, - `blank_page`—opens the pagein a new tab. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `blank_page` | |`merchant_fail_url` string, optional |URL for final redirection to the web service by customer decision when a purchase is declined. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `https://cosmoshop.jupiter.example/pages/failed` | |`merchant_return_enabled` integer, optional |Indicator that specifies the availability options for the preliminary redirection of the customer to the web service from the payment form. Can have one of the following values: - `0`—redirectionto the web service is not available, - `1`—redirectionto the web service is available if Payment Page is opened in a separate browser tab\(in this case, how the web service page is opened is determined by the corresponding parameter from the `mode` group\) and not as an iframe object or in a modal window, - `2`—redirectionto the web service is available by default, using the mode specified in the `mode` parameter group. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `0` | |`merchant_return_redirect_mode` string, optional |Indicator that specifies the mode for the preliminary redirection of the customer to the web service from the payment form. Can have one of the following values: - `iframe`—opens the pagein an iframe object \(this value is ignored if the payment form is opened in a new tab and the customer is redirected in that new tab\), - `parent_page`—opens the pagein the currently active tab, - `blank_page`—opens the pagein a new tab. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `iframe` | |`merchant_return_url` string, optional |URL for preliminary redirection to the web service from the payment form. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `https://cosmoshop.jupiter.example/return` | |`merchant_success_enabled` integer, optional |Indicator that specifies the availability options for the final redirection of the customer to the web service when the purchase is completed. Can have one of the following values: - `0`—redirectionto the web service is not available, - `1`—redirectionto the web service is available if Payment Page is opened in a separate browser tab\(in this case, how the web service page is opened is determined by the corresponding parameter from the `mode` group\) and not as an iframe object or in a modal window, - `2`—redirectionto the web service is available by default, using the mode specified in the `mode` parameter group. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `1` | |`merchant_success_redirect_mode` string, optional |Indicator that specifies the mode for the final redirection of the customer to the web service when the purchase is completed. Can have one of the following values: - `iframe`—opens the pagein an iframe object \(this value is ignored if the payment form is opened in a new tab and the customer is redirected in that new tab\), - `parent_page`—opens the pagein the currently active tab, - `blank_page`—opens the pagein a new tab. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `parent_page` | |`merchant_success_url` string, optional |URL for final redirection to the web service by customer decision when the purchase is completed. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `https://cosmoshop.jupiter.example/pages/success` | |`mode` string, optional |Indicator that specifies the Payment Page operation mode. Can have one of the following values: - `purchase`—for making a purchasein Purchase mode \(used by default\), - `payout`—for making a payoutin Payout mode, - `card_verify`—for verifying the validity of a payment instrumentin Card Verify mode, - `card_tokenize`—for creating a payment details tokenin Card Tokenize mode. Example: `card_verify` | |`moto_type` integer, optional |Type of order for carrying outa Mail Order/Telephone Order purchase\(involving the owner of the payment card providing its details over phone, mail, fax, or email\): - `1`—Mail Order, - `2`—Telephone Order. Example: `2` | |`operation_type` string, optional |Indicator that specifieswhether a purchaseis processed in one or two steps. Should be specified in cases where the intended payment type is different from the one specified by default \(with regard to the number of steps\). Can have one of the following values: - `sale`—for one-step purchases \(with the funds transferred to the merchant immediately;[details](en_pp_purchase.md)\), - `auth`—for two-step purchases \(with the funds transferred to the merchant after first being in an authorisation hold;[details](en_pp_purchase_auth.md)\). Example: `auth` | |`payment_amount` integer, required\* |The amount of the paymentin the smallest currency unit. Specified in the smallest currency unit without a decimal separator.Required for all Payment Page modes except Card Tokenize. Example: `1815`\(represents an amount of 18.15 currency units when referring to a currency with two decimals\) | |`payment_cryptocurrency_type` string, optional |Indicator that specifies the type of the cryptocurrency. Required for payments involving cryptocurrencies via the Mastercard MoneySend and Visa Direct services. Can have one of the following values: - `cbdc`—a central bank digital currency or tokenized deposit issued by a central bank, reserve bank, or other national monetary authority. - `stablecoins_fiat_backed`—a fiat-backed digital asset with reserves held by a licensed financial institution. - `native_tokens`—a digital currency native to a specific blockchain, required for transactions within its network, including fee payments. - `other`—a non-fiat digital asset that does not fit other types or cannot be classified at the time of transaction initiation. Example: `cbdc` | |`payment_currency` string, required\* |Three-letter code of the payment currency. Specified in the ISO-4217 alpha-3 format, according to the [currency codes reference](en_currency_codes.md).Required for all Payment Page modes except Card Tokenize. Pattern: `^[A-Z]{3}$`. Example: `EUR` | |`payment_description` string, optional |A short description for the payment, intended to be displayed to the customer, as well as being used by the web service for tracking purposes. The length of the string cannot be more than 255 characters. Can be displayed to the customer on the information page, or via system notifications and the Dashboard interface. Example: `Thai massage session` | |`payment_extra_param` string, optional |Additional relevant information pertaining to the payment. May be required for specific payment methods and in other individual cases.Generally, where and how this parameter is used, as well as the format of any data contained therein should be decided uponduring the integration of the web service, or when implementing additional payment methods or capabilities. | |`payment_id` string, required\* |The payment identifier. Must be assigned by the web service. Should consist of a string no longer than 255 characters, be case-insensitive, and correspond one-to-one with the relevant payment within that project.Required for all Payment Page modes except Card Tokenize. Example: `payment_443` | |`payment_merchant_risk` string, optional |Additional information about a purchase made for goods or services by a customer and about which 3‑D Secure authentication method is preferred by the merchant. Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme.The JSON object can include various combinations of elements from the list of supported data. When passed for card payments, data contained in this parameter may serve to improve the probability of a successful 3‑D Secure authentication without any further input from the customer \(i.e., authentication via the frictionless flow instead of the challenge flow; [details](en_pp_3ds.md#)\). - `challenge_indicator`, string, `^0[1-9]$`—indicates whether the challenge flow is preferred. Possible values: - `01`—no preferences - `02`—not using the challenge flow is preferred - `03`—using the challenge flow is preferred - `04`—using the challenge flow is required - `05`—do not use the challenge flow, the merchant has performed the risk analysis - `06`—do not use the challenge flow, use the Data Only flow - `07`—do not use the challenge flow, Strong Customer Authentication has been applied otherwise - `08`—do not use the challenge flow, the merchant is included in cardholder's trusted beneficiaries list - `09`—using the challenge flow is required, prompt the cardholder to add the merchant to the trusted beneficiaries list - `challenge_window`, string, `^0[1-5]$`—the dimensions of a window in which the authentication page opens. Possible values: - `01`—250 x 400 px - `02`—390 x 400 px - `03`—500 x 600 px - `04`—600 x 400 px - `05`—full screen - `gift_card`, object—object with information about a purchase made with a prepaid or gift card: - `amount`, integer—the amount of the purchase made with a prepaid or gift card in the smallest units of currency - `count`, integer—total number of prepaid or gift cards used for making a purchase - `currency`, string—the currency of the purchase made with a prepaid or gift card in the ISO 4217 alpha-3 format - `preorder_date`, string, `^\\d{2}-\\d{2}-\\d{4}$`—the date when the preordered merchandise or service will be available in the `DD-MM-YYYY` format - `preorder_purchase`, string, `^0[1-2]$`—indicates whether the purchase is a preorder. Possible values: - `01`—not a preorder - `02`—a preorder - `reorder`, string, `^0[1-2]$`—indicates whether the customer is buying the merchandise or the service for the first time or it is a repeat purchase. Possible values: - `01`—first-time purchase - `02`—repeat purchase ```language-json { "payment":{ "reorder":"01", "preorder_purchase":"01", "preorder_date":"11-10-2022", "challenge_indicator":"01", "challenge_window":"01", "gift_card":{ "amount":12345, "currency":"USD", "count":1 } } } ``` ``` eyAKICAicGF5bWVudCI6eyAKICAgICJyZW9yZGVyIjoiMDEiLAogICAgInByZW9yZGVyX3B1cmNoYXNlIjoiMDEiLAogICAgInByZW9yZGVyX2RhdGUiOiIxMS0xMC0yMDIyIiwKICAgICJjaGFsbGVuZ2VfaW5kaWNhdG9yIjoiMDEiLAogICAgImNoYWxsZW5nZV93aW5kb3ciOiIwMSIsCiAgICAiZ2lmdF9jYXJkIjp7IAogICAgICAiYW1vdW50IjoxMjM0NSwKICAgICAgImN1cnJlbmN5IjoiVVNEIiwKICAgICAgImNvdW50IjoxCiAgICB9CiAgfQp9== ``` | |`payment_methods_options` string, optional |Additional information relevant for specific payment methods and third-party services. Can be used to manage individual methods, including Open Banking methods, in order to send additional information about the customer and the payment, manage the page size of third-party web services that the customer is redirected to, and for other possible reasons, depending on the specific payment methods being used. Example: `{\"online_thailand_banks\": {\"split_banks\": true}}` | |`project_id` integer, required |Identifier of the projectintended to manage the interactions of the web service with the payment platform. This identifier is assigned by Ecommpayduring the integration \([details](en_glossary.md#)\). Example: `57123` | |`receipt_data` string, optional |Information about line items in an order. Can be used to generate a proof of purchase document to be sent to the customer \(see [this article](en_PP_receipt_data.md)\).Consists of a string obtained by encoding a JSON object using the Base64 encoding scheme.The JSON object can include various combinations of elements from the list of supported data. - `positions`, array—array which allows listing up to 300 purchased items in the notification. For each listed item, the following information can be specified: - `amount`, integer—the price of the item - `quantity`, integer—the number of purchased items of the same kind - `tax`, integer—the VAT rate if it differs for different listed items - `tax_amount`, integer—the VAT amount - `description`, string—the description of the purchased item. - `total_tax_amount`, integer—the total VAT amount for the entire purchase - `common_tax`, integer—the VAT rate if it is the same for all listed items ``` {#codeblock_vd1_r3b_d2c .language-json} { "receipt_data":{ "positions":[ { "quantity":3, "amount":10000, "tax":18, "tax_amount":1800, "description":"Design frame" } ], "total_tax_amount":1800, "common_tax":18 } } ``` ``` {#codeblock_k1g_r3b_d2c} receipt_data: "eyAgCiAgICAgICJwb3NpdGlvbnMiOlsgIAogICAgICAgICB7ICAKICAgICAg ICAgICAgInF1YW50aXR5IjozLAogICAgICAgICAgICAiYW1vdW50IjoxMDAwMCwKICAgICAgICAgICAgInRheCI 6MTgsCiAgICAgICAgICAgICJ0YXhfYW1vdW50IjoxODAwLAogICAgICAgICAgICAiZGVzY3JpcHRpb24iOiJEZXN pZ24gZnJhbWUiCiAgICAgICAgIH0KICAgICAgXSwKICAgICAgInRvdGFsX3RheF9hbW91bnQiOjE4MDAsCiAgICA gICJjb21tb25fdGF4IjoxOCAgICAgICAKfQ" ``` | |`recipient_address` string, optional |The name of the street and the house number\(including any additional parts of the address such as building indicators and apartment numbers\) in the address of the payment recipient. The length of the string cannot be more than 99 characters.Required for Visa Direct debiting operations performed with Visa cards issued in Australia, Canada, or New Zealand. Example: `Via Dietro Duomo 36` | |`recipient_card_holder` string, optional |The first and last names of the holder of the payment card used to receive the payment. Should be spelled as specified on the card and adhere to the rules for specifying names \(see [this article](en_faq_payment_processing.md#section_dbx_kby_t1c)\). The length of the string cannot be more than 255 characters. Example: `Fran Petrarca` | |`recipient_city` string, optional |The name of the place of residence \(e.g., town, city, or other settlement type\) in the address of the payment recipient. The length of the string cannot be more than 25 characters. Example: `Padova` | |`recipient_country` string, optional |The country code of the place of residence of the payment recipient. Specified in the ISO 3166-1 alpha-2 format. Pattern: `^[A-Z]{2}$`. Example: `IT` | |`recipient_day_of_birth` string, optional |The date of birth of the payment recipient. Specified in `DD-MM-YYYY` format. Required if a Visa card is used to receive the payment. Pattern: `^\\d{2}-\\d{2}-\\d{4}$`. Example: `12-12-1990` | |`recipient_first_name` string, optional |The name of the payment recipient. The length of the string cannot be more than 255 characters. Example: `Fran` | |`recipient_last_name` string, optional |The last name of the payment recipient. The length of the string cannot be more than 255 characters. Example: `Petrarca` | |`recipient_pan` string, optional |The number of the payment card used to receive the payment. Specified as is, without masked characters, spaces, or other separators. Pattern: `^[0-9]{15,19}$`. Example: `4314220000000056` | |`recipient_state` string, optional |The local code of the region\(state, province, or other administrative subdivision type\) of the payout recipient's address \([details](en_Gate_payout.md)\). The value of this parameter is the second element of a code for a subdivision \(in ISO 3166-2\), without the two-letter country code and the hyphen-minus used as a separator. Should be specified for processing payouts when the `recipient_country` parameter is also specified in the same query and its value is the country code of Canada \(`CA`\) or the United States \(`US`\). Pattern: `^[A-Z]+$`. Example: `AK`\(when specified for Alaska, designated `US-AK`\) | |`recipient_state_code` string, optional |The local code of the region\(state, province, or other administrative subdivision type\) associated with the recipient's address for fund transfers using Mastercard MoneySend and Visa Direct services \([details](en_gate_money_transfer_services.md#)\). The value of this parameter is the second element of a code for a subdivision \(in ISO 3166-2\), without the two-letter country code and the hyphen-minus used as a separator. Should be specified for Mastercard MoneySend and Visa Direct operations when the `recipient_country` parameter is also specified in the same query and its value is the country code of Canada \(`CA`\) or the United States \(`US`\). Pattern: `^[A-Z]+$`. Example: `ON`\(when specified for Ontario, designated `CA-ON`\) | |`recipient_wallet_id` string, optional |The identifier of the digital wallet used by the payment recipient. The length of the string cannot be more than 64 characters. Specified as is, without masked characters, spaces, or other separators. Pattern: `^[^!@&~№{}|<>\\[\\]]*$`. Example: `WID20071304` | |`recipient_wallet_owner` string, optional |The first and last names of the owner of the digital wallet used by the payment recipient. Should be spelled the same way as in the payment system and be at most 255 characters long in total. Pattern: `/^[\p{L}\p{M}0-9 .'-]+$/u`. Example: `Fran Petrarca` | |`recurring` string, optional |Information about the COF purchase being registered \([details](en_pp_recurring.md)\). If the Ecommpay JavaScript library is used, can be passed as a JSON object\(containing various combinations of elements from the list of supported data\), otherwise should be specified as a URLobtained by encoding the source JSON object. - `register`, boolean—indicator that specifies whether a COF purchase should be registered - `type`, string, `^[RCU]$`—type of the COF purchase to register, possible values: - `R`—regular purchase - `C`—one-click purchase - `U`—autopurchase - `period`, string, `^[DWMQY]$`—frequency of debits \(for a regular COF purchase\), possible values: - `D`—daily - `W`—weekly - `M`—monthly \(if the set day is not available in the next month, for example, 31, the payment is performed on the last day of the month\) - `Q`—quarterly - `Y`—annually - `amount`, integer—fixed amount of subsequent debits \(for a regular COF purchase\) in the smallest currency unit - `interval`, integer—multiplier to increase debiting frequency \(i.e. the interval of performing regular COF purchases\). This parameter is used in conjunction with the `period` parameter and should be assigned a numeric value from `1` to `100` - `time`, string, `^([0-1][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]$`—time of performing subsequent debits \(for a regular COF purchase\) in the `hh:mm:ss` format. The parameter is used if the `period` parameter is specified in the request - `start_date`, string, `^([0-3]\\d-){2}[1-2]\\d{3}$`—date on which the first debit operation is performed \(for a COF regular purchase\). This parameter is used in conjunction with the `scheduled_payment_id` parameter and should be specified in the `DD-MM-YYYY` format - `expiry_day`, integer orstring—calendar day on which the specified duration period of the COF purchase will end \(the value should be provided as an integer from `1` to `31`, without a leading zero, in accordance with the Gregorian calendar\) - `expiry_month`, integer orstring—month in which the specified duration period of the COF purchase will end \(the value should be provided as an integer from `1` to `12`, without a leading zero, in accordance with the Gregorian calendar\) - `expiry_year`, integer—year in which the specified duration period of the COF purchase will end \(in the `YYYY` format, in accordance with the Gregorian calendar\) - `scheduled_payment_id`, string—identifier assigned to the payment within which scheduled debits are performed, it must differ from the identifier of the payment made to register a COF purchase that is specified in `payment_id` ```language-json { "register": true, "type": "U" } ``` ```language-json %7B%22register%22%3Atrue%2C%22type%22%3A%22U%22%7D%2C ``` | |`redirect` integer \(boolean\*\), optional |Indicator specifying whether the payment form should be opened on a new HTML page regardless of the type of device being used \(see [this article](en_PP_method_NewTab.md#)\). Can have one of the following values: - `0`—the payment form should beopened usingeither the default method or a different method specified in other parameters, - `1`—the payment form should beopened in a new HTML page. If the `merchant.js` library is used \([details](en_pp_interaction_organisation.md#)\), this parameter can be specified as a boolean value and set to either `false` or `true`. Example: `1` | |`redirect_fail_mode` string, optional |Indicator that specifies the mode for the final redirection of the customer to the web service when the purchase is declined. Can have one of the following values: - `iframe`—opens the pagein an iframe object \(this value is ignored if the payment form is opened in a new tab and the customer is redirected in that new tab\), - `parent_page`—opens the pagein the currently active tab, - `blank_page`—opens the pagein a new tab. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `blank_page` | |`redirect_fail_url` string, optional |URL for final redirection to the web service if the purchase is declined. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `https://cosmoshop.jupiter.example/pages/failed` | |`redirect_on_mobile` integer \(boolean\*\), optional |Indicator specifying whether the payment form should be opened on a new HTML page for mobile devices \(see [this article](en_PP_method_NewTab.md#)\). Can have one of the following values: - `0`—the payment form should beopened using eitherthe default method or a different method specified in other parameters, - `1`—the payment form should beopened in a new HTML page. If the `merchant.js` library is used \([details](en_pp_interaction_organisation.md#)\), this parameter can be specified as a boolean value and set to either `false` or `true`. Example: `1` | |`redirect_success_mode` string, optional |Indicator that specifies the mode for the final redirection of the customer to the web service when the purchase is completed. Can have one of the following values: - `iframe`—opens the pagein an iframe object \(this value is ignored if the payment form is opened in a new tab and the customer is redirected in that new tab\), - `parent_page`—opens the pagein the currently active tab, - `blank_page`—opens the pagein a new tab. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `parent_page` | |`redirect_success_url` string, optional |URL for final redirection to the web service by customer decision when a purchase is completed. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `https://cosmoshop.jupiter.example/pages/success` | |`redirect_return_url` string, optional |URL for preliminary redirection to the web service from third-party services such as banks and other payment systems. Requires this functionality \(for specific third-party services\) to be set up and enabled beforehand. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `https://cosmoshop.jupiter.example/pages/third_party_services` | |`redirect_tokenize_mode` string, optional |Indicator that specifies the mode for the automatic final redirection of the customer to the web service when a token has been generated in Card Tokenize mode using the relevant payment details. Can have one of the following values: - `iframe`—opens the pagein an iframe object \(this value is ignored if the payment form is opened in a new tab and the customer is redirected in that new tab\), - `parent_page`—opens the pagein the currently active tab. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `parent_page` | |`redirect_tokenize_url` string, optional |URL for automatic final redirection to the web service when a token has been generated in Card Tokenize mode using the relevant payment details. For more information about managing options for redirecting the customer back to the web service, see [this article](en_PP_redirect_modes.md#). Example: `https://cosmoshop.jupiter.example/pages/tokenize` | |`region_code` string, optional |The country code for the customer's address. Specified in the ISO 3166-1 alpha-2 format. If this parameter is not specified, the country code is determined using the customer's IP address or other parameters. Pattern: `^[A-Z]{2}$`. Example: `FR` | |`sender_address` string, optional |The name of the street and the house number\(including any additional parts of the address such as building indicators and apartment numbers\) in the address of the payment sender. The length of the string cannot be more than 99 characters. Example: `Via Certaldo 18` | |`sender_city` string, optional |The name of the place of residence \(e.g., town, city, or other settlement type\) in the address of the payment sender. The length of the string cannot be more than 25 characters. Example: `Florence` | |`sender_country` string, optional |The code of the country in the address of the payment sender. Specified in the ISO 3166-1 alpha-2 format. Pattern: `^[A-Z]{2}$`. Example: `IT` | |`sender_descriptor` string, optional |Information about the merchant provided to other parties involved in card payment processing and subsequently to customers. Can be used for issuing payouts. The length of the string is limited to 22 characters for cards of the Mastercard card network and 25 characters for cards of the Visa card network. For more information on working with this parameter, see [this article](en_pp_descriptor.md). Example: `Cosmotour* to the Moon` | |`sender_first_name` string, optional |The first name of the payment sender. The length of the string cannot be more than 255 characters. Example: `Gio` | |`sender_last_name` string, optional |The last name of the payment sender. The length of the string cannot be more than 255 characters. Example: `Boccaccio` | |`sender_state` string, optional |The local code of the region\(state, province, or other administrative subdivision type\) of the payment sender's address. The value of this parameter is the second element of a code for a subdivision \(in ISO 3166-2\), without the two-letter country code and the hyphen-minus used as a separator. Should be specified when the `sender_country` parameter is also specifiedin the same query. Example: `52`\(when specified for Tuscany, designated `IT‑52`\) | |`sender_wallet_id` string, optional |The identifier of the digital wallet used by the payment sender. The length of the string cannot be more than 64 characters. Specified as is, without masked characters, spaces, or other separators. Example: `WID16061313` | |`sender_zip` string, optional |The postal code in the address of the payment sender. The length of the string cannot be more than 255 characters. Example: `50142` | |`signature` string, required |The digital signature used to sign the query parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified \(see [this article](en_platform_signature.md#)\). | |`style_id` integer, optional |The identifier of the payment form design style. Can be used for the Payment Page design style \(see [this article](en_PP__design_customisation.md#)\). Example: `6123` | |`target_element` string, optional |The iframe element identifier\(for the HTML page of the web service\) of the element where the payment form should be opened \(see [this article](en_PP_method_Embedded.md#)\). Example: `widget-container` | |`uuid` string, optional |Identifier used for internal purposes. The length of the string cannot be more than 64 characters.Can be used to invoke the payment form in Payout modeby specifying the value received in the payout registration callback \(see [this article](en_pp_payout.md)\). Example: `Lm3V9lmykig2d51Z/2Yrnue9+o5GTkVvY/sRDLKAnSS+AagnGCJ1nsPg==` | **Parent topic:**[Payment Page](en_PP_about.md) --- # Gate {#en_Gate_Integration_About .concept} A section with the information about working with the the Gate API. This section provides the information about working with the Gate interface. ## Overview {#section_yww_4nc_stb .section} The information about the interfaceand the basic actions available during the work with the interface—[Overview](en_Gate_How_to_Integrate.md). ## Integration {#section_bbj_fpc_stb .section} The information about the integration with the Ecommpay payment platform via Gate: - [Quickstart](en_gate_quickstart.md#)—about quick and easy ways to start accepting payments and to implement other capabilities with the use of PHP and Go code examples. - [Interaction concepts](en_gate_interaction_organisation.md#)—about integrating with the payment platform via Gate and the interaction formats and workflows utilised in the process. ## Basic actions {#section_y53_dsc_stb .section} The information about the basic actions available during the work via Gate: - [One-time purchases](en_Gate_purchase.md)—about processing purchases with immediate debiting of funds\([one-step purchases](en_gate_payment_sale.md#)\) and with debiting after authorisation hold \([two-step purchases](en_gate_payment_auth.md#)\). - [Payment link purchases](en_gate_invoice.md#)—about processing one-stepand two-step purchases with the use of payment links and with the customer redirection to the Payment Page payment form. - [Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md)—about registering and processing purchases with the subsequent series of recurring debits. - [Purchase refunds](en_Gate_Refund.md)—about returning the funds that were debited from the customer's account within a particular purchase. - [Payouts](en_Gate_payout.md)—about processing payouts with the transfer of funds from the merchant to the customer. - [Payment instrument verification](en_gate_account_verification.md)—about debiting a dummy \(zero\) amount or authorising a specific \(non-zero\) amount to verify a payment instrument. ## Auxiliary procedures and additional capabilities {#section_ddb_gzc_stb .section} The information about various procedures and capabilities that can be used for processing payments via Gate: - [Auxiliary procedures](en_gate_procedures.md)—about the procedures that can be required for processing separate payments. - [Additional capabilities](en_Gate_Additional_capabilities.md)—about the capabilities that can be useful for boosting payment acceptance rates, customer convenience, and the quality of the provided services. ## API specification {#section_xkk_v1d_stb .section} The information about the data structuresin program requests and responses—[API Reference](https://api-developers.ecommpay.com/). - **[Overview](en_Gate_How_to_Integrate.md)** An article with the introductory information about the Gate interface and its capabilities. - **[Quickstart](en_gate_quickstart.md#)** A quickstart guide on how to implement payment processing via Gate with the use of source code examples in PHP and Go. - **[Interaction concepts](en_gate_interaction_organisation.md#)** An article about organising the work with Gate on the web service side based on the principles of the payment platform operation and the utilised interaction flows and formats. - **[One-time purchases](en_Gate_purchase.md)** Articles about processing via Gate one-time purchases with immediate debiting of funds \(one step\) and with debiting of funds after placing an authorization hold \(two steps\). - **[Payment link purchases](en_gate_invoice.md#)** An article about processing one-step and two-step purchases with the use of payment links and redirecting customers to Payment Page. - **[Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md)** Articles about registering and processing via Gate different types of purchases followed by a series of recurring debits and about the capabilities of managing debits within recurring payments. - **[Purchase refunds](en_Gate_Refund.md)** An article about refunding different types of purchases via Gate. - **[Payouts](en_Gate_payout.md)** An article about processing payouts via Gate. - **[Payment instrument verification](en_gate_account_verification.md)** An article about verifying a payment instrument via Gate by debiting a zero amount or placing a hold on funds. - **[Auxiliary procedures](en_gate_procedures.md)** Articles about auxiliary procedures that can be required during processing specific payments via Gate. - **[Additional capabilities](en_Gate_Additional_capabilities.md)** Articles about additional capabilities of Gate for boosting payment acceptance rates, customer convenience, and the quality of the provided services. - **[Gate API](gate_api.md)** The Gate API specification with the descriptions of data structures and schemas for generating requests to different endpoints. --- # Overview {#en_Gate_How_to_Integrate .concept} An article with the introductory information about the Gate interface and its capabilities. Gate is one of the Ecommpay payment platform, and it provides a full range of capabilities for interaction with the payment platform. Gate supports performing one-time purchases and COF purchases,refunds and payouts, as well as requesting additional information, for instance, a payment status.You can integrate with the platform solely via Gate, or you can combine using Gate with other Ecommpay interfaces and solutions. For example, you can set up processing purchases via Payment Page and issue payouts and refunds via Gate. Gate allows you to accept card paymentsand alternative payments \(for more information, see [Methods](en_pm_about.md)\). Payments with direct use of payment cards are supported for American Express, Mastercard, Visa, CUP \(only for payouts\). To process payments via Gate, you need to develop your own payment interface, with full UI control.Processing card payments via Gate requires your payment interface to be a PCI compliant \(for more information about necessary documents, contact your Ecommpay account manager\). ![](images/en_gate_scheme_1.svg) In general, while performing a payment, the web service sends a request to one of the Gate API endpoints. Then the payment platform receives the request, processes and redirects it to third parties participating in payment processing and responds with a callback contained the final payment result. The sections about Gate cover the following: - [Interaction concepts](en_gate_interaction_organisation.md#)—how to integrate by using Gate, technical aspects on interaction between the web service and the payment platform, including interaction models and the formats of request, response and callback. - [Payment processing](en_platform_payment_model.md)—overview information about payment types provided in the payment platform, processing of each payment types, payment statuses as well as objects related to payment—requests and operations. - [One-time purchases](en_Gate_purchase.md), [Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md), [Payouts](en_Gate_payout.md), [Payment instrument verification](en_gate_account_verification.md)—technical aspects on processingall types of payments such as purchases, COF purchases, payments and card verification. - Other sections with information on Gate. **Parent topic:**[Gate](en_Gate_Integration_About.md) --- # One-time purchases {#en_Gate_purchase .concept} Articles about processing via Gate one-time purchases with immediate debiting of funds \(one step\) and with debiting of funds after placing an authorization hold \(two steps\). This section covers information on processing of one-time purchases.General information, which extends the section about payment models and statuses \([Payment processing](en_platform_payment_model.md)\), is applicable to payments with payment cards and payments by using alternative instruments, while the detailed information is only applicable to payments with payment cards. For more information about payments by alternative instruments, see [Methods](en_pm_about.md). **Warning:** In order to enhance the quality of payment processing and ensure compliance with industry standards, starting from January 15, 2026, merchants in certain business categories must specify the `booking_info` object containing information about the start and end dates of the booked service \([details](en_gate_additional_data.md#)\), for each initiated [card purchase](en_pm_cardpayments.md). This requirement applies to merchants with [Merchant Category Codes \(MCC\)](en_glossary.md#) 3000–3999, 4411, 4511, 4722, 5962, 6513, 7011, 7012, 7512, 7519, and 7922. *One-time purchase* is a payment type which makes a one-time transfer of funds from customer to merchant. The Ecommpay payment platform supports the following *types* of one-time purchases: - *One-step purchase*, or *one-time one-step purchase*, is a payment type which uses only one request to make a one-time transfer of funds from customer to merchant.You can use this purchase type toprocess payments by using payment cards and alternative payment instruments and to implement repayment of loans issued by microlenders. The purchase workflow and format of requests and callbacks are covered in greater detail in the following section: [One-step purchase](en_gate_payment_sale.md#). - *Two-step purchase*, or *one-time two-step purchase*, is a payment type which uses two steps to make a one-time transfer of funds from customer to merchant. On the first step, merchant initiates an authorization hold—in other words, the purchase amount is deducted from the credit limit of customer's card account. On the second step, the purchase amount is 'captured', or, in other words, it is transferred to the merchant account based on the merchant request or after specific time lag.Two-step purchases are supported for payment processing by using payment cards and alternative payment instruments.The purchase workflow and format of requests and callbacks are covered in greater detail in the following section: [Two-step purchase](en_gate_payment_auth.md#). Information about possible statuses of this payment type can be found in [the corresponding article](en_platform_sms_model.md). - **[One-step purchase](en_gate_payment_sale.md#)** An article about processing via Gate one-time one-step purchases with immediate debiting of funds. - **[Two-step purchase](en_gate_payment_auth.md#)** An article about processing via Gate one-time two-step purchases that comprise placing an authorization hold and subsequent debiting of funds. **Parent topic:**[Gate](en_Gate_Integration_About.md) --- # Credential-on-file \(COF\) purchases {#en_Gate__payments_on_saved_data .concept} Articles about registering and processing via Gate different types of purchases followed by a series of recurring debits and about the capabilities of managing debits within recurring payments. **Note:** This subsection covers processing COF purchases via Gate and describes requests and callbacks that are used in case of card payments. In addition, use the following materials to gain a fuller understanding of processing COF purchases: - articles [On-demand COF purchase](en_platform_recurring_model.md) and [COF purchase with automatic debiting](en_platform_sheduled_recurring_model.md) in the section [Payment processing](en_platform_payment_model.md) that provide a general description of processing COF purchases in the Ecommpay payment platform and cover information about operations utilised to execute a payment of this type and statuses that are assigned to the payment and the operations performed within it. - articles of the [Payment methods](en_pm_about.md) section containing a description of processing COF purchases via Gate with the focus on the specific features of the payment method used and information about relevant requests and callbacks. In this article: - [Overview](en_Gate__saved_cards_payments_type.md) - [Registering COF purchase](en_gate_payment_recurring_registration.md) - [On-demand COF purchase](en_Gate__cof_merchant_side.md) - [COF purchase with automatic debiting](en_Gate__cof_gate_side.md#) - [Managing debiting series of a COF purchase](en_gate_payment_recurring_manage.md) - [Working with debiting retry attempts](en_gate_cof_retry_attempts.md#) - **[Overview](en_Gate__saved_cards_payments_type.md)** An article with the general information about recurring purchases, their classification, and processing workflows. - **[Registering COF purchase](en_gate_payment_recurring_registration.md)** An article about registering via Gate purchases followed by series of recurring debits. - **[On-demand COF purchase](en_Gate__cof_merchant_side.md)** An article about processing via Gate recurring purchases with debiting of funds initiated by the merchant \(unscheduled\). - **[COF purchase with automatic debiting](en_Gate__cof_gate_side.md#)** An article about processing via Gate recurring purchases with automatic debiting of funds \(according to a set schedule\). - **[Managing debiting series of a COF purchase](en_gate_payment_recurring_manage.md)** An article about the capabilities of managing debiting series of recurring purchases via Gate, including retrieval of information about the debiting series, updating its parameters, and canceling the recurring purchase. - **[Working with debiting retry attempts](en_gate_cof_retry_attempts.md#)** An article about working with the automatic debiting retries as part of processing a recurring purchase. **Parent topic:**[Gate](en_Gate_Integration_About.md) --- # Overview {#en_Gate__saved_cards_payments_type .concept} An article with the general information about recurring purchases, their classification, and processing workflows. ## Definition {#section_ldx_hjk_w2b .section} *COF purchase* is a payment type in which customer authorizes merchant to store customer's payment credentials for subsequent use for one or more later transfers of funds from customer to merchant. In COF purchases, no payment instrument verification \(for instance,card CVV entry\) is required. In COF purchases, fund transfers from customer to merchant are called *debiting*. ## Overview {#section_bzg_ghw_slb .section} COF purchase support may be useful for building long-term customer loyalty when you need to offer your customers easy and hassle-free checkout. The payment platform supports the following COF payment types: - *One-click purchase* is initiated by customer occasionally without any schedule or amount limitation or terms. For instance, customer can make a one-click purchase of a movie to view it online. - *Autopurchase* is initiated by merchant without any schedule or amount limitation or terms. For example, when customer's mobile phone account balance falls below specific threshold, merchant may automatically top up the account. - *Regular purchase* is initiated by merchant based on specific schedule and fixed amount. The debiting terms may be stored either on the payment platform or in your web service. For example, weekly online subscription may be regularly debited to customer's account. ![](images/en_cof.svg) To process any COF purchase, regardless of its type, you need to collect the customer's consent to subsequent storing and use of their payment details according to specific terms and conditions \(that conform to the requirements of global card networks \). As a rule, collecting such consent is carried out when the COF purchase is registered. ## Processing options {#section_fhj_2h1_v3b .section} Any COF purchase needs to be *registered*. You can do it in a variety of ways: for example, by performing a one-step purchase or payment instrument verification with the use of the corresponding request with appropriate parameters \([details](en_gate_payment_recurring_registration.md)\). In addition, COF purchases can be registered elsewhere and subsequently migrated to the Ecommpay payment platform from an external acquirer \([details](en_gate_data_migration.md#)\) or even performed without migrating their data to the platform. Information about COF purchases already registered can be *stored* in the Ecommpay platform or elsewhere \(in the merchant's web service or on the side of the external acquirer\). Note that within one project only one way to store data can be configured. Thus, if for a specific project, you have already set up processing COF purchases with the payment details stored outside of the Ecommpay platform, then processing COF purchases with the payment details stored in the platform will not be allowed, and vice versa. COF purchases can be *processed* as follows. There are two processing options available for regular COF purchases with registration data stored in the Ecommpay platform: - [with automatic debiting](en_Gate__cof_gate_side.md#) when each debit operation is initiated in the platform according to a previously configured schedule. - [with on-demand debiting](en_Gate__cof_merchant_side.md) when each debit operation is initiated by the merchant. Other types of COF purchases \(i.e. they are not regular COF purchases or information about them is not stored in the platform\) can only be processed using the on-demand debiting option. In addition, regardless of the selected processing option, COF purchases can be performed according to the standard workflow or with the auxiliary procedure of [submitting additional payment information](en_Gate_Clarification.md). **Parent topic:**[Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md) --- # Registering COF purchase {#en_gate_payment_recurring_registration} An article about registering via Gate purchases followed by series of recurring debits. ## Overview {#section_qx5_hhm_dlb .section} To register a COF purchase with the payment platform, you need to save customer payment instrument credentials. You can do it in a variety of ways by processing payments via Gate, Payment Page \([details](en_pp_recurring.md)\), and Dashboard \([details](en_dbl_payments.md#)\)as well as by migrating information about COF purchases from an external acquirer \([details](en_gate_data_migration.md#)\). You can register a COF purchase via Gate by sending a request for one-time purchase, payment link purchase, or for payment instrument verification with parameters indicating that the payment instrument credentials need to be saved. Each COF purchase is registered for a defined period. If the merchant does not specify parameters defining this period, the platform applies default values corresponding either to the expiry date of the relevant payment card or to a period of 10 years from the month in which the COF purchase was registered \([details](en_gate_payment_recurring_registration.md#ul_jld_fw3_y3b)\). Once the period the COF purchase was registered for expires, the payment platform sends a callback with this information to merchant's web service. Any further debiting within this purchase is no longer possible; if web service attempts to initiate the debit operation, the payment platform will respond with a callback with the `3184` \(or `3301`\) error code. **Note:** According to Visa and Mastercard recommendations issued in 2020, they temporary allow COF purchases with expired bank cards, provided the payment provider or the payment system support this option. In this case, purchases are possible both before and after card expiration date, if the COF registration date is set to the card expiration date. To prevent using expired bank cards for COF purchases, when registering COF purchase, set its expiry date to the date which is different from the card expiry date \(see [Updating debit series](en_gate_payment_recurring_manage.md#section_lpp_df2_5jb) for more information\). COF purchase registration may be blocked for specific merchant projects or providers in which case the requests with registration demand may be declined. To prevent declining of such requests, you can contact support service at [support@ecommpay.com](mailto:support@ecommpay.com) and ask them to configure your project to ignore registration demands when processing COF purchases, if COF purchase registration is blocked. If there are changes in the payment provider's service settings, you may need to register COF purchase again. In such cases, the merchant receives an email from the Ecommpay technical support with a list of IDs of COF purchases that should be re-registered. For this registration, merchant must notify customers of the termination of previous debits and the need to initiate new ones by unlinking the saved card, and then initiate registration in the platform. Each newly registered COF purchase receives a new ID, which is sent to the merchant in the callback with information on successful registration. ## Registration procedure {#section_p3r_frb_cjb .section} To register a COF purchase, you need to send a request to initiate one of the following operations: `sale`, `auth`, `account verification`, or `invoice` and to populate the request with all the parameters required to process the operation *and* the parameters required to register the COF purchase. The payment platform initiates and performs the requested operation including any auxiliary procedures which may be required. If credentials are stored on the payment platform, after the operation is successfully completed and is assigned the `success` status, a record about debiting series is created on the payment platform. The record is assigned the following attributes: - *ID* Once the record about debiting series is created, web service receives its ID in the callback inside the `id` parameter of the `recurring` object. You use this ID to perform and to manage COF purchases. - *Status* Any active debiting series record is assigned the `active` status. The status may change to `canceled` on merchant or customer demand and in some other cases. If credentials are stored in the web service, a record about debiting series is not created. The payment platform sends your web service a callback with operation result that contains ID of the debiting series record, if this record has been created. Such callback confirms that COF purchase is successfully registered. ## Registration when credentials are stored by web service {#section_smg_vqb_cjb .section} There are several things you must consider when performing a COF purchase with customer instrument credentials stored by web service: 1. You need to use a POST request to one of the following endpoints: - [/v2/payment/card/sale](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale)—when processing a one-time one-step purchase - [/v2/payment/card/auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth)—when processing a one-time two-step purchase - [/v2/payment/card/account\_verification](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification)—when verifying the payment instrument - [/v2/payment/card/account\_verification/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification-token) when verifying the payment instrument with the use of a token 2. Your request must contain all the required parameters and objects. 3. Also, your request must include the `stored_card_type` parameter and specify COF purchase type by using one of the following values: - `3`—autopurchase - `5`—regular purchase \(except for requests to the endpoint [/v2/payment/card/account\_verification/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification-token)\). Thus, along all the required parameters, complete request must contain registration flags for selected COF purchase. ```language-json { "general": { "project_id": 42, "payment_id": "456789", "signature": "v7KNeR+CqGrNxYyilUwSm...==" }, "card": { "pan": "4314220000000056", "year": 2025, "month": 8, "card_holder": "JUDY DOE", "cvv": "123", "stored_card_type": 3 // Registering autopurchase }, "customer": { "id": "customer_12", "ip_address": "202.144.196.0" }, "payment": { "amount": 400, "currency": "USD" } } ``` The payment platform includes the COF purchase registration information in its operation result callback to your web service. The payment platform uses the standard format for callbacks. For more information, see [Handling callbacks](en_platform_callbacks.md#). ```language-json { "project_id":42, "payment":{ "id":"567890", "type":"purchase", "status":"success", "date":"2019-05-14T12:52:45+0000", "method":"card", "sum":{ "amount":400, "currency":"USD" }, "description":"" }, "account":{ "number":"431422******0056", "token":"d927d3f006008edf5c07661", "type":"visa", "card_holder":"JUDY DOE", "expiry_month":"08", "expiry_year":"2025" }, "customer":{ "id":"customer_12" }, "scheme\_id":"MCS38A0790706", "operation":{ "id":22136002040, "type":"sale", "status":"success", "date":"2019-05-14T12:52:45+0000", "created_date":"2019-05-14T12:52:42+0000", "request_id":"8c53d11-1160d2c", "sum_initial":{ "amount":400, "currency":"USD" }, "sum_converted":{ "amount":400, "currency":"USD" }, "provider":{ "id":414, "payment_id":"00200011764", "date":"2019-05-14T12:52:55+0000", "auth_code":"231567", "endpoint_id":414 }, "code":"0", "message":"Success", "eci":"07" }, "signature":"v7KN5D/aZAdeR+CqGrNxYyilUwSm...==" } ``` ## Registration when credentials are stored by the payment platform {#section_vdl_vqb_cjb .section} There are several things you must consider when registering a COF purchase with customer instrument credentials stored by the payment platform: 1. You need to use a POST request to one of the following endpoints: - [/v2/payment/card/sale](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale)—when processing a one-time one-step purchase - [/v2/payment/card/auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth)—when processing a one-time two-step purchase - [/v2/payment/card/account\_verification](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification)—when verifying the payment instrument - [/v2/payment/invoice/create](https://api-developers.ecommpay.com/api-specification/payment-links/post-v2-payment-invoice-create)—when initiating a payment link purchase - [/v2/payment/invoice/card/token/create](https://api-developers.ecommpay.com/api-specification/payment-links/post-v2-payment-invoice-card-token-create)—when initiating a payment link purchase with the use of a token 2. Your request must contain all the required parameters and objects. 3. Also, your request must include a `recurring` object with the parameters of the COF purchase to register: - `register`—indicator that specifies whether a COF purchase should be registered. - `type`—type of the COF purchase to register, possible values: - `C`—one-click purchase - `U`—autopurchase - `R`—regular purchase - `time`—time of performing subsequent debits \(for a regular COF purchase\) in the `hh:mm:ss` format. The parameter is used if the `period` parameter is specified in the request. - `period`—frequency of debits \(for a regular COF purchase\), possible values: - `D`—daily - `W`—weekly - `M`—monthly \(if the set day is not available in the next month, for example, 31, the payment is performed on the last day of the month\) - `Q`—quarterly - `Y`—yearly 4. You can also use other parameters of the `recurring` object: - `amount`—fixed amount of subsequent debits \(for a regular COF purchase\) in the smallest currency unit. - `interval`—multiplier to increase debiting frequency \(i.e. the interval of performing regular COF purchases\). This parameter is used in conjunction with the `period` parameter and should be assigned a numeric value from `1` to `100`. For example, if you need to charge the customer every third week, you can set `period` to `W` and `interval` to `3`. - `start_date`—date on which the first debit operation is performed \(for a COF regular purchase\). This parameter is used in conjunction with the `scheduled_payment_id` parameter and should be specified in the `DD-MM-YYYY` format. - `expiry_day`—calendar day on which the specified duration period of the COF purchase will end \(the value should be provided as an integer from `1` to `31`, without a leading zero, in accordance with the Gregorian calendar\). - `expiry_month`—month in which the specified duration period of the COF purchase will end \(the value should be provided as an integer from `1` to `12`, without a leading zero, in accordance with the Gregorian calendar\). - `expiry_year`—year in which the specified duration period of the COF purchase will end \(in the `YYYY` format, in accordance with the Gregorian calendar\). **Note:** If any of the parameters defining the expiry date of the COF purchase is not provided in the request, the following default values apply: - For standard card payments—the corresponding parameter value \(day, month, year\) is determined based on the expiry date of the specified payment card. - For other available methods—the corresponding parameter value is determined as follows: - Calendar day—the last calendar day of the relevant month \(as specified in the `expiry_month` parameter or corresponding to the COF purchase registration date\). - Month—the month in which the COF purchase was registered. - Year—the year that is 10 years after the year in which the COF purchase was registered. Accordingly, if only the year is specified, for standard card payments the day and month are taken from the expiry date of the relevant card and combined with the specified year. For an alternative payment method, the expiry date is set to the last calendar day of the month in which the COF purchase was registered and the specified year. - `scheduled_payment_id`—identifier assigned to the payment within which scheduled debits are performed. It must differ from the identifier of the payment made to register a COF purchase and must be unique within the project. Also, not to be confused with the debiting series record identifier specified in the `id` parameter of the `recurring` object that is passed in the callback with the COF purchase registration information. **Warning:** If the identifier that should be assigned to the COF purchase \(`scheduled_payment_id`\) matches the identifier of the payment made to register a COF purchase \(`payment_id`\), the request to register a COF purchase is declined. Thus, along all the required parameters, complete request must contain registration flags for selected COF purchase and its type; for regular purchases, request must also contain debiting schedule. Depending on the specific characteristics of providers involved in payment processing, the set of required parameters can vary. For the detailed information about the providers' requirements, contact the Ecommpay key account manager. ```language-json { "general": { "project_id": 42, "payment_id": "567890", "signature": "v7KN1ZZ5D/aZAeR+CqGrwSm...==" }, "card": { "pan": "4314220000000056", "year": 2025, "month": 8, "card_holder": "JUDY DOE", "cvv": "123" }, "customer": { "id": "customer_12", "ip_address": "202.144.196.0" } "payment": { "amount": 400000, "currency": "USD" }, "recurring": { "type": "R", // Regular purchase "period": "W", "interval": 3, // Debiting every third week "expiry_year": 2025, "expiry_month": 5, "expiry_day": 5, // Last debiting scheduled for May 5, 2025 "time": "10:00:00", // Debit at 10:00:00 "register": true, // COF purchase registration "scheduled_payment_id": "567891", "start_date": "10-10-2020" } } ``` Information about registering a COF purchase is communicated in callbacks with operation results sent from the payment platform to the web service. The format of these callbacks conforms to the standard one described in [this article](en_platform_callbacks.md#).In addition, callbacks can be configured to include the `scheme_id` parameter that will contain the identifier of the operation that registered a COF purchase on the side of the global card network. To have it set up, you need to contact the Ecommpay technical support. The following callback contains information about successful registration of a COF purchase with a debiting series record identifier `1001648059`. ```language-json { "project_id":42, "payment":{ "id":"567890", "type":"purchase", "status":"success", "date":"2019-05-14T12:52:45+0000", "method":"card", "sum":{ "amount":400, "currency":"USD" }, "description":"" }, "account":{ "number":"431422******0056", "token":"d927d3f006008edf5c07661", "type":"visa", "card_holder":"JUDY DOE", "expiry_month":"08", "expiry_year":"2025" }, "customer":{ "id":"customer_12" }, "recurring":{ "id":1001648059, // ID of debiting series record "currency":"USD", "valid_thru":"2019-05-20T00:00:00+0000" }, "scheme\_id":"MCS38A0790706", "operation":{ "id":22136002040, "type":"sale", "status":"success", "date":"2019-05-14T12:52:45+0000", "created_date":"2019-05-14T12:52:42+0000", "request_id":"8c77279053d011-1160421d51e11f87d2c", "sum_initial":{ "amount":400, "currency":"USD" }, "sum_converted":{ "amount":400, "currency":"USD" }, "provider":{ "id":414, "payment_id":"00200011764", "date":"2019-05-14T12:52:55+0000", "auth_code":"231567", "endpoint_id":414 }, "code":"0", "message":"Success", "eci":"07" }, "signature":"v7KNMpZ1ZZ5D/aZAebR+CqGrUwSm...==" } ``` **Parent topic:**[Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md) --- # On-demand COF purchase {#en_Gate__cof_merchant_side .concept} An article about processing via Gate recurring purchases with debiting of funds initiated by the merchant \(unscheduled\). ## Overview {#section_knp_r41_v3b .section} *On-demand COF purchase* is a payment type which uses a single initial request to make one \(recurring\) transfer of funds from customer to merchant by using previously stored payment credentials without validation of the payment instrument \(such ascard validation code\). On-demand COF purchases can be processed if one of the following conditions is met: - These purchases were initially registered in the payment platform \([details](en_gate_payment_recurring_registration.md)\). - Information about these purchases was migrated from an external acquirer \([details](en_gate_data_migration.md#)\). - Information about these purchases was not migrated to the platform, but you have coordinated their processing with your Ecommpay account manager, and it has been set up for the project. In the Ecommpay payment platform, on-demand COF purchases are processed according to the payment model \([details](en_platform_recurring_model.md)\) and the workflow described in this article. Note that conditions pertinent to registration as well as steps of the registration flow do not apply to COF purchases registered anywhere else but the Ecommpay platform. In addition, the following applies to COF purchases that were registered elsewhere and the information of which was not migrated to the platform: - If the capability to perform such purchases is set up for the project, then other kinds of COF purchases \(registered in the platform or migrated to it\) cannot be processed within this project. - If payments are made with cards issued in the EEA, the merchant is responsible for registering COF purchases in compliance with the Strong Customer Authentication \(SCA\) requirement of the revised Directive on payment services \(PSD2\). ## The payment workflow {#section_mft_gvd_w3b .section} To create a COF purchase: 1. Register a COF purchase. For more information, see [Registering COF purchase](en_gate_payment_recurring_registration.md). 2. Submit a request for [a COF purchase](en_Gate__cof_merchant_side.md#section_jbj_flf_dlb) with identifier of debiting series record. 3. Accept [a callback with debiting result](en_Gate__cof_merchant_side.md#section_wxc_s41_v3b) from the payment platform. For each subsequent debiting, you need to resubmit request for COF purchase and accept the callback with the debiting result. ![](images/en_gate_uml_oneclick.svg) 1. Customer initiates debiting in the web service. 2. The web service sends a request for debiting to the Ecommpay URL. 3. The payment platform receives the request. 4. The payment platform processes the request. 5. The payment platform sends to the web service the information about receiving the request and the correctness of the request. 6. The payment platform sends request to perform payment to the payment system. 7. The payment system processes the request and sends it to the issuer. 8. The issuer processes the request and debits customer account or card. 9. The issuer sends notification with payment results to the payment system. 10. The payment system sends the notification with payment results to the payment platform. 11. The payment platform sends callback with debiting results to the web service. 12. The web service sends debiting result to customer. 13. From this point forward, customer can initiate subsequent debiting that follow steps 1—12. ![](images/en_gate_uml_autopayment.svg) 1. The web service sends a request for debiting to the Ecommpay URL. 2. The request enters the payment platform. 3. The payment platform processes the request. 4. The payment platform sends to the web service the request acknowledgement and request correctness information. 5. The payment platform sends the request to perform purchase to the payment system. 6. The payment system processes the request and forwards it to the issuer. 7. The issuer processes the request and debits customer account or card. 8. The issuer sends notification with payment results to the payment system. 9. The payment system sends the notification with payment results to the payment platform. 10. The payment platform sends callback with debiting results to the web service. 11. The web service sends debiting result to customer. 12. From this point forward, customer can initiate subsequent debiting each following steps 1 through 12. The sections that follow discuss formats for requests and callbacks; for general information about using the API, see [Interaction concepts](en_gate_interaction_organisation.md#). Information about possible statuses of this payment type can be found in [the corresponding article](en_platform_payment_model.md). ## Request format {#section_jbj_flf_dlb .section} This section describes format of the requests for COF purchases with on-demand debiting using *payment cards*.There are several things you must consider when submitting such requests: 1. The request must be sent with the use of the POST method to one of the following endpoints: - [/v2/payment/card/recurring](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-recurring)—for all types of COF purchases that were initially registered in the Ecommpay platform or that were migrated to the platform, regardless of where the payment details are stored \(in the payment platform or the merchant's web service\). - [/v2/payment/card/sale](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale)—for COF purchases with the payment details stored in the merchant's web service, regardless of where the COF purchase was initially registered. - [/v2/payment/card/auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth)—only for autopurchases and regular COF purchases with the payment details stored in the merchant's web service, regardless of where the COF purchase was initially registered. - [/v2/payment/card/account\_verification/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification-token)—only for autopurchases that were initially registered in the Ecommpay platform or that were migrated to the platform, with the payment details stored in the merchant's web service. 2. Your request must contain the following parameters and objects: - `general`—object with general request identification information: - `project_id`—project ID obtained from Ecommpay - `payment_id`—payment ID, must be unique within the project - `signature`—signature created after you specify all the required parameters \(For more information about signing requests, see [Signature generation and verification](en_platform_signature.md#).\) - `customer`—object with customer information: - `ip_address`—customer IP address relevant for the initiated payment - `id`—customer identifier unique within the project, the same identifier as the one used to register this COF purchase **Warning:** Using different customer identifiers for operations performed as part of the COF purchase is not allowed. - `payment`—object with payment information: - `amount`—payment amount in minor currency units - `currency`—payment currency according to ISO-4217 alpha-3 - `cryptocurrency_type`—the indicator that specifies the type of the cryptocurrency, required for Mastercard and Visa payments involving cryptocurrencies. This parameter should be assigned one of the following values: - `cbdc`—a central bank digital currency or tokenized deposit issued by a central bank, reserve bank, or other national monetary authority - `stablecoins_fiat_backed`—a fiat-backed digital asset with reserves held by a licensed financial institution - `native_tokens`—a digital currency native to a specific blockchain, required for transactions within its network, including fee payments - `other`—a non-fiat digital asset that does not fit other types or cannot be classified at the time of transaction initiation 3. Depending on the endpoint, you must add the following objects and parameters in the request: - The request to the [/v2/payment/card/recurring](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-recurring) endpoint must contain the `id` parameter in the `recurring` object, and the value of this parameter must be the identifier of the debit series record received in the callback with registration information. - The requests to the [/v2/payment/card/sale](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale) endpoint must contain the `card` object with the following parameters: - `pan`—card number - `year`—card expiration year - `month`—card expiration month - `card_holder`—name of the cardholder, passed if this parameter is required for the specific project \(the name must be spelled as specified on the card; note that if you want to make this parameter optional instead of required, it can only be done upon consultation with your account manager which includes examination and assessment of associated risks\) - `stored_card_type`—purchase type \(`4` for autopurchase or `6` for regular purchase\) - `scheme_id`—identifier of the initial operation of the COF purchase registration. This identifier is assigned by the global card network \(Mastercard or Visa\), is required when a COF purchase is registered in the European Economic Area, and can be specified in other cases. - The requests to the [/v2/payment/card/account\_verification/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification-token) endpoint must contain the `stored_card_type` parameter of the `card` object, and this parameter must have the value `4` \(autopurchase\). 4. Additionally, you can use any other parameters as indicated in the specification. Thus, a complete request must contain project ID, payment ID, signature, customer IP, payment amount and currency and either of the following:ID of debit series recordor payment card credentials and COF purchase type. Depending on the specific characteristics of providers involved in payment processing, the set of required parameters can vary. For the detailed information about the providers' requirements, contact the Ecommpay key account manager. ```language-json { "general":{ "project_id":42, "payment_id":"456789", "signature":"v7KNMp5D/aZAeb0VMdeR+CqGSm...==" }, "customer":{ "ip_address":"202.144.196.0", "id":"customer_12" }, "payment":{ "amount":400, "currency":"USD" }, "recurring":{ "id":1079 // ID of debit series record } } ``` ```language-json { "general":{ "project_id":42, "payment_id":"456789", "signature":"v7KftZ5D/aZAdeR+qGrNxY...==" }, "customer":{ "ip_address":"202.144.196.0", "id":"customer_12" }, "payment":{ "amount":400, "currency":"USD" }, "card": { "pan": "4314220000000056", "year": 2025, "month": 8, "card_holder": "JOHN SMITH", "stored_card_type": 4 // Automatic debiting } } ``` ```language-json { "general":{ "project_id":42, "payment_id":"456789", "signature":"v7KftZ5D/aZAdeR+qGrNxY...==" }, "customer":{ "ip_address":"202.144.196.0", "id":"customer_12" }, "payment":{ "amount":400, "currency":"USD" }, "token":"pkmawa3khb7wninntq8g8q3592fjjxwvzfebwbegqkl1c16akpgo6sgxac6wulz7", "card":{ "stored_card_type": 4 // Automatic debiting } } ``` ## Callback format {#section_wxc_s41_v3b .section} Results of processing COF purchases are communicated in callbacks with information about each performed debiting sent from the payment platform to the web service. The format of these callbacks conforms to the standard one described in [this article](en_platform_callbacks.md#).In addition, callbacks can be configured to include the `scheme_id` parameter that will contain the identifier of the operation that registered a COF purchase on the side of the global card network. To have it set up, you need to contact the Ecommpay technical support. The following callback contains information about debiting `4,00 USD` to card `431422******0056` of the customer with ID `customer_12` within the `42` project. ```language-json { "project_id":42, "payment":{ "id":"456789", "type":"recurring", "status":"success", "date":"2019-09-04T12:57:57+0000", "method":"card", "sum":{ "amount":400, "currency":"USD" }, "description":"" }, "account":{ "number":"431422******0056", "type":"visa", "card_holder":"JUDY DOE", "id":45678, "expiry_month":"08", "expiry_year":"2025" }, "recurring":{ "id":1079, "currency":"USD", "valid_thru":"2022-10-31T00:00:00+0000" }, "operation":{ "id":39690002636, "type":"recurring", "status":"success", "date":"2019-09-04T12:57:57+0000", "created_date":"2019-09-04T12:57:53+0000", "request_id":"0b9f9e57a50-61da119c", "sum_initial":{ "amount":400, "currency":"USD" }, "sum_converted":{ "amount":400, "currency":"USD" }, "provider":{ "id":414, "payment_id":"0020000000072964", "date":"2019-09-04T12:58:03+0000", "auth_code":"634R", "endpoint_id":414 }, "code":"0", "message":"Success" }, "scheme_id": "MCS38A0790706", "signature":"MpfogAxZ5D/b0VMdeR+xYyilUwSm...==" } ``` **Parent topic:**[Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md) --- # Managing debiting series of a COF purchase {#en_gate_payment_recurring_manage} An article about the capabilities of managing debiting series of recurring purchases via Gate, including retrieval of information about the debiting series, updating its parameters, and canceling the recurring purchase. The payment platform allows you to manage debiting for any COF purchase types by doing the following: - getting information about debiting series - updating COF purchase parameters: change debit amount and expiration date for all COF purchase types and modify debit schedule for regular COF purchases - cancelling COF purchase at any time Note that customer can at any time contact the issuer and have COF purchase cancelled. In this case, any following debiting operation is cancelled and the stored payment instrument credentials are deleted from the payment platform. In addition, you can manage settings of regular COF purchases by using [Dashboard](en_dbl_payments.md#). ## Getting information about debiting series {#section_vkt_cf2_5jb .section} There are several things you must consider when sending a request for information about debit series: 1. You need to use a POST request to one of the [/v2/payment/recurring/info](https://api-developers.ecommpay.com/api-specification/direct-debit/post-v2-payment-recurring-info) endpoint. 2. Your request must contain the following parameters and objects: - `general`—object with general request identification information: - `project_id`—project ID obtained from Ecommpay - `signature`—signature created after you specify all the required parameters \(For more information about signing requests, see [Signature generation and verification](en_platform_signature.md#).\) - ID of the debit series inside the `id` parameter of the `recurring` object previously received in the callback with COF purchase registration information Thus, complete request must contain project ID, signature, and ID of debit series. ```language-json { "general":{ "project_id":42, "signature":"v7KNMpfogMdeR+CqGrNxYyilUwSm...==" }, "recurring":{ "id":1079 } } ``` The payment platform uses the standard format for response with debit series information.For more information about response format, see [Response format](en_gate_interaction_organisation.md#). The following response contains information about debiting `4,00 USD` to card `431422******0056` of the customer with ID `customer_12` within the `42` project. The response also notifies that subsequent debiting is possible. ```language-json { "project_id":42, "recurring":{ "id":1079, // Debit series ID "type": "R", "period": "W", "period_interval": 3, "start_date": "2020-10-20", "start_time": "10:00:00", "amount": 100, "last_payment_at": "0000-00-00 00:00:00", "valid_thru": "2025-05-25 00:00:00", "status": "active", "currency": "USD", "payment\_method": "card" } } ``` ## Updating debit series {#section_lpp_df2_5jb .section} There are several things you must consider when sending a request for updating debit series: 1. You need to use a POST request to one of the [/v2/payment/card/recurring/update](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-recurring-update) endpoint. 2. Your request must contain the following parameters and objects: - `general`—object with general request identification information: - `project_id`—project ID obtained from Ecommpay - `payment_id`—payment ID, must be unique within the project - `signature`—signature created after you specify all the required parameters \(For more information about signing requests, see [Signature generation and verification](en_platform_signature.md#).\) - `recurring`—object with the COF payment information: - `id`—ID of debit series received in the callback with COF purchase registration data 3. You need also use other parameters of the `recurring` object: - `period`—frequency of debits \(for a regular COF purchase\), possible values: - `D`—daily - `W`—weekly - `M`—monthly \(if the set day is not available in the next month, for example, 31, the payment is performed on the last day of the month\) - `Q`—quarterly - `Y`—yearly - `interval`—multiplier to increase debiting frequency \(i.e. the interval of performing regular COF purchases\). This parameter is used in conjunction with the `period` parameter and should be assigned a numeric value from `1` to `100`. - `time`—time of performing subsequent debits \(for a regular purchase\) in `hh:mm:ss` format. The parameter is used if the `period` parameter is specified in the request. - `amount`—fixed amount of subsequent debits in the smallest currency unit. - `start_date`—date on which the first debit operation is performed \(for a COF regular purchase\). This parameter is used in conjunction with the `scheduled_payment_id` parameter and should be specified in the `DD-MM-YYYY` format. - `expiry_day`—calendar day on which the specified duration period of the COF purchase will end \(the value should be provided as an integer from `1` to `31`, without a leading zero, in accordance with the Gregorian calendar\). - `expiry_month`—month in which the specified duration period of the COF purchase will end \(the value should be provided as an integer from `1` to `12`, without a leading zero, in accordance with the Gregorian calendar\). - `expiry_year`—year in which the specified duration period of the COF purchase will end \(in the `YYYY` format, in accordance with the Gregorian calendar\). **Note:** If any of the parameters defining the expiry date of the COF purchase is not provided in the request, the following default values apply: - For standard card payments—the corresponding parameter value \(day, month, year\) is determined based on the expiry date of the specified payment card. - For other available methods—the corresponding parameter value is determined as follows: - Calendar day—the last calendar day of the relevant month \(as specified in the `expiry_month` parameter or corresponding to the COF purchase registration date\). - Month—the month in which the COF purchase was registered. - Year—the year that is 10 years after the year in which the COF purchase was registered. Accordingly, if only the year is specified, for standard card payments the day and month are taken from the expiry date of the relevant card and combined with the specified year. For an alternative payment method, the expiry date is set to the last calendar day of the month in which the COF purchase was registered and the specified year. - `scheduled_payment_id`—identifier assigned to the payment within which scheduled debits are performed. It must differ from the identifier of the payment made to register a COF purchase and must be unique within the project. Thus, complete request must contain project ID, payment ID, signature, ID of debit series, and debit series parameters to update. ```language-json { "general":{ "project_id":42, "payment_id":"456789", "signature":"v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" }, "recurring":{ "id":1079, "interval":3, "period":"M", "time":"12:00:00" } } ``` The payment platform uses the standard format for callbacks with information about updating debit series. For more information about callback format, see [Handling callbacks](en_platform_callbacks.md#). The following callback affirms that COF purchase is set to perform debiting every third month at 12:00:00. ```language-json { "project_id":123, "recurring":{ "id":1079, // ID of debit series record "currency":"USD", "status":"active", // Debit series status "type":"R", "expiry_month":"5", // Month when COF purchase expires "expiry_year":"2025", // Year when COF purchase expires "period":"M", // Debiting period "period_interval":3, "time":"12:00:00" // Time to perform debiting }, "signature":"IL9tVftZ1ZZ5D/b0VMdeR+YyilUwSm...==" } ``` ## Cancel COF purchase {#section_wkc_2f2_5jb .section} There are several things you must consider when sending a request to cancel COF purchase: 1. You need to use a POST request to one of the [/v2/payment/card/recurring/cancel](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-recurring-cancel) endpoint. 2. Your request must contain the following parameters and objects: - `general`—object with general request identification information: - `project_id`—project ID obtained from Ecommpay - `payment_id`—payment ID, must be unique within the project - `signature`—signature created after you specify all the required parameters \(For more information about signing requests, see [Signature generation and verification](en_platform_signature.md#).\) - ID of the debit series inside the `id` parameter of the `recurring` object previously received in the callback with COF purchase registration information Thus, complete request must contain project ID, payment ID, signature, and ID of debit series. ```language-json { "general":{ "project_id":42, "payment_id":"456789", "signature":"VftZ1ZZ5D/aMdeR+CqilUwSm...==" }, "recurring":{ "id":1079 } } ``` The payment platform uses the standard format for callbacks with information about cancelling COF purchase. For more information about callback format, see [Handling callbacks](en_platform_callbacks.md#). The following callback update that the COF purchase with ID `1079` has been cancelled. ```language-json { "project_id":42, "recurring":{ "id":1079, // Debit series ID "currency":"USD", "status":"canceled", // Status indicates COF purchase is cancelled "type":"R", "expiry_month":"5", "expiry_year":"2025", "period":"M", "period_interval":3, "time":"12:00:00" }, "signature":"MpfogAxwRItZ1Z/AeMde+GrNYyUwSm...==" } ``` **Parent topic:**[Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md) --- # Purchase refunds {#en_Gate_Refund .concept} An article about refunding different types of purchases via Gate. In the context of the Ecommpay payment platform, *refund* is a repayment of the money customer previously paid in a purchase operation. Refund *does not apply*, if the money were not previously actually transferred from customer to merchant, for example, if customer's money are held as a result of an authorization hold operation, the amount will be returned through releasing the authorization hold, but not through a refund. For more information, see [Two-step purchase](en_gate_payment_auth.md#)\). To perform refunds, you can use Gate and/or Dashboard. This section discusses how to perform refunds by using Gate.Note that general information is relevant for both cards and other payment instruments while the technical information applies only to card operations. For technical information about other payment instruments, see Methods. ## General information {#section_uxb_p52_dlb .section} The payment platform supports refund for one-time purchases and COF purchases. In general, there is no time limit for making a refund after purchase is complete, though some payment methods may impose timeout after which refund may be no longer possible or require additional fee. To make a refund using Gate, you need to submit the corresponding request to the `/v2/payment/\{payment\_method\}/refund` endpoint. When doing so, you need to observe all the special aspects and limitations as described in other sections in this documentation. In general, depending on the refund amount, one of the following operations is performed: - `reversal`—the refund is initiated for the initial purchase amount *and* before the current business day closing - `refund`—the refund is initiated in either of the following scenarios: the refund is initiated for a fraction of the initial purchase amount on the same business day *or* the refund is initiated after the purchase business day closing for either fraction or total initial amount. Though, there is an exception in this rule for the purchases with Visaor American Express cards: operation type depends only on timing: - `reversal` operation is created, if the refund is initiated before the current business day closing. - `refund` operation is created, if the refund is initiated after the current business day is closed. **Note:** The business day here is understood as the time period which is used for clearing purposes. Normally, this is 24 hours, though it may be adjusted to account for day-light saving time. Business day start and end times may differ because of different factors, therefore it is advised to contact the Ecommpay support to get the most accurate information. To sum up: refund is supported for one-time and COF purchases, it is started by using a single request which initiates either `refund` or `reversal` operation. ![Diagram of relations between request for refund, payment type, and operation](images/en_gate_model_refund.svg "Diagram of relations between request for refund, payment type, and operation") Once a refund is complete, the payment platform sends to the web service a callback with refund completion result and the information about the current purchase status. After refund, purchase status can be one of the following: - `success`—purchase is complete, refund is not performed. - `reversed`—refund is performed in full before the current business day completion. - `refunded`—refund is performed in full after the current business day completion. - `partially reversed`—refund is performed for a fraction of the initial purchase amount before the current business day completion \(applicable only to Visaand American Express cards\). - `partially refunded`—refund is performed for a fraction of the initial purchase amount. \(For Visaand American Express cards, refund is performed after the current business day completion.\) - `scheduled recurring processing`—refund is performed for full or partial amount of the initial COF purchase. Note that this does not affect any future COF purchases. ## Special aspects {#section_o1n_dwl_5jb .section} The refund performing period depends on the issuing bank or payment provider which performs the operation, and may take a long time. Any refund changes the payment amount. The callback includes information about the actual payment amount still available for further refunds. The actual payment amount is calculated as the initial purchase amount minus all the amounts repaid to customer. Suppose that the initial purchase amount is `13.70 USD`. Then, if you make a `10.00 USD`  refund, the actual payment amount will be `3.70 `USD. If you make another refund for `3.70 USD`, the actual payment amount will be zero. The rule also applies to any recurrent purchases where the actual payment amount is the total of all purchases minus all refunds. Depending on payment method, some refund aspects can differ, for instance additional commission may be charged for late refunds. For more information about special refund aspectsfor specific payment methods, see [Methods](en_pm_about.md) or contact your account manager at Ecommpay. ## Limitations {#section_g2m_fpf_5jb .section} When performing refunds, you need to observe the following limitations: - The initial purchase must include at least one money transfer and the purchase status must be one of the following: `success`, `scheduled recurring processing`, or `partially refunded`. If the initial purchase did not result in any money transfer or if the purchase status is not one of the listed above statuses, the refund request is declined and the payment platform sends to your web service a callback with the `3281` error code. - Refund currency must me the same as the initial purchase currency. If the currency in your refund request differs from the initial purchase currency, the refund is declined and the payment platform sends to your web service a callback with the `3284` error code. \(For more information about error codes, see [Handling operation processing information](en_platform_payment_info_codes.md).\) - The time between consecutive attempts to send refund request must not be too small. If you send a repeated refund request within two minutes after the previous attempt, the refund will be declined and the payment platform will send your web service a callback with the `3285` error code. - The merchant account balance must be adequate to perform the refund. To check your account balance, you can use [Data API](https://api-data.ecommpay.com/)\(see [Using Data API](en_dbl_api_protocol.md) for details\) or Dashboard \(see [Financial accounting](en_dbl_balances.md#) for details\). Alternatively, you can contact your account manager at Ecommpay. - Specific region requirement for refunds and requirements imposed by payment service providers and payment processors must be observed. For example, in Republic of Belarus, only one refund operation is allowed for each purchase.For more information about special refund features of specific payment methods, see [Methods](en_pm_about.md) or contact your account manager at Ecommpay. - There must be no chargeback claims pending for the purchase for which refund is requested. If there are any chargeback claim pending for the purchase, the refund request is declined and the payment platform sends to your web service a callback with the `3288` error code. Additionally, the following limitations apply to partial refunds: - Partial refund amount cannot exceed the initial purchase amount, otherwise the refund request is declined and the payment platform sends to your web service a callback with the `3283` error code. - After processing a partial refund of a card payment, the actual payment amount should be at least 0.01 USD. The actual amount is checked on the payment platform side after the refund is initiated, the rates are used if the payment currency is other than USD. If the requirement is not met, the refund request is declined and a callback wit the `3117` error code is sent to the web service. - New partial refund can be initiated only if any previous partial refund in complete, otherwise the refund request is declined and the payment platform sends to your web service a callback with the `3285` error code. For the information about request and callback formats for card operations, see below. For the information about request and callback formats for other payment methods, see [Methods](en_pm_about.md). ## Request format {#section_jwj_mf1_sjb .section} Refund request format complies with general request format regulations as described in [Interaction concepts](en_gate_interaction_organisation.md#), and the target endpoint for the request is [/v2/payment/card/refund](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-refund). The request body must contain the following objects and parameters: - `general`—object with general request information, contains the following parameters: - `project_id`—the project ID obtained from Ecommpay - `payment_id`—payment ID for which refund need to be performed - `signature`—signature created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#)\). - `payment`—object with payment information which contains the following parameters: - `description`—description of the reason for refunding. This parameter is relevant only for refund operations. Passing this parameter does not modify in any way the description of the initial purchase if such description was included in the initial purchase request. The description of the reason for refunding can be passed in callbacks as a value of the `operation_description` parameter. This parameter is not used by default, but it can be added to the data set passed in callbacks upon coordination with the technical support specialists. The parameter set listed above allows you to make only a full refund. To make a partial refund, you need to add the following parameters in the `payment` object: - `amount`—refund amount in minor currency units, must be not larger than the actual purchase balance - `currency` — payment currency in the ISO-4217 alpha-3 format, must be same as the initial purchase currency Additionally, you can use any other parameters as specified in the Gate API specification. To sum up: any refund request must include project and payment IDs, signature, refund description, as well as currency code and amount, if required. ```language-json { "general": { "project_id": 239, "payment_id": "payment2", "signature": "of8k9xeKJ7KLTZYO56lCv+f1M0Sf/7eg==" }, "payment": { "description": "refund", // For partial refund: "amount": 1000, "currency": "USD" } } ``` ## Callback format {#section_ens_mf1_sjb .section} Callback with refund result complies with general callback format regulations described in [Handling callbacks](en_platform_callbacks.md#). The actual payment amount information is contained in the `payment` object, the information about the amount repaid to the customer is included in the `operation` object. Also, callback may include refund description in the `operation_description` object, if the support service have activated this option when onboarding. **Note:** If several refunds are performed for a single purchase, each refund operation is assigned a separate identifier. The identifier is placed in the `operation_id` parameter inside the `operation` object. Below, you will find examples of callbacks for two refund scenarios for an initial purchase with amount `13.70 USD`: 1. Partial `10.00 USD` refund with the `partially refunded` status that makes the actual payment amount equal `3.70 USD`. 2. Full `13.70 USD` refund with the `refunded` status that makes the actual payment amount equal `0.00 USD`. Each example shows the purchase description included in the initial payment request and a description of refund reason. ```language-json { "project_id":239, "payment":{ "id":"payment2", "type":"purchase", // Purchase type: one-time purchase "status":"partially refunded", // Purchase status after partial return "date":"2019-11-13T14:52:14+0000", "method":"card", "sum":{ "amount":370, // Actual payment amount "currency":"USD" // Payment currency code }, "description":"Thai massage session" // Payment description }, "account":{ "number":"431422******0056", "type":"visa", "card_holder":"JUDY DOE", "expiry_month":"03", "expiry_year":"2023" }, "operation_description":"Deficient service", // Refund reason "operation":{ "id":3862, "type":"refund", // Operation type "status":"success", // Operation status "date":"2019-11-13T14:52:15+0000", "created_date":"2019-11-13T14:52:12+0000", "request_id":"0c4457b5fe8dada59-e7b58eceb8aecfa791-00049391", "sum_initial":{ "amount":1000, // Refund amount "currency":"USD" // Refund currency code (same as initial purchase currency) }, "sum_converted":{ "amount":1000, "currency":"USD" }, "code":"0", "message":"Success", "provider":{ "id":414, "payment_id":"", "endpoint_id":414 } }, "signature":"of8k9xerKSK4XL1QFaDH3p9Mh0CIcjmOwSwKJ7KLTZYO56lCv+f1M0Sf/7eg==" } ``` ```language-json { "project_id":239, "payment":{ "id":"payment2", "type":"purchase", // Payment type: one-time purchase "status":"refunded", // Payment status after full refund "date":"2019-11-13T13:52:09+0000", "method":"card", "sum":{ "amount":0, // Actual payment amount "currency":"USD" // Payment currency }, "description":"Thai massage session" // Payment description }, "account":{ "number":"431422******0056", "token":"14c24c8a5384b413f11b2956a82ddaeea609ea49", "type":"visa", "card_holder":"JUDY DOE", "expiry_month":"03", "expiry_year":"2023" }, "customer":{ "id":"1478" }, "operation_description":"Service cancellation", // Refund reason "operation":{ "id":3861, "type":"refund", // Operation type "status":"success", // Operation status "date":"2019-11-13T13:52:09+0000", "created_date":"2019-11-13T13:52:08+0000", "request_id":"67a97cd6b14f1aa0543c81e18cd270b66-aadc6e790206d5-00038611", "sum_initial":{ "amount":1370, // Refund amount "currency":"USD" // Refund currency code (same as initial purchase currency) }, "sum_converted":{ "amount":1370, "currency":"USD" }, "code":"0", "message":"Success", "provider":{ "id":414, "payment_id":"", "endpoint_id":414 } }, "signature":"of8k9xerKSK4XL1QFaDH3p9Mh0CIcjmOwSwKJ7KLTZYO56lCv+f1M0Sf/7eg==" } ``` Here is a example in which a refund of `7.99 EUR` is performed for a COF purchase with multiple purchases totaling `7.99 EUR`. This makes the actual payment amount equal to `0.00 EUR`. In this case, the payment status does not change because more purchases are expected for the payment. \(For more information about payment statuses, see [Payment processing](en_platform_payment_model.md).\) ```language-json { "project_id":239, "payment":{ "id":"payment3", "type":"recurring", // Payment type: COF purchase "status":"scheduled recurring processing", // Payment status after refund "date":"2019-11-13T17:23:26+0000", "method":"card", "sum":{ "amount":0, // Actual payment amount "currency":"EUR" // Payment currency }, "description":"Thai massage session" // Payment description }, "account":{ "number":"431422******0056", "token":"14c24c8a5384b413f11b2956a82ddaeea609ea49", "type":"visa", "card_holder":"JUDY DOE", "expiry_month":"03", "expiry_year":"2023" }, "customer":{ "id":"1478" }, "recurring":{ "id":1061, "currency":"EUR", "valid_thru":"2027-05-31T00:00:00+0000" }, "operation_description":"Refund for payment3 order", // Refund reason "operation":{ "id":3861, "type":"refund", // Operation type "status":"success", // Operation status after successful refund "date":"2019-11-13T17:23:26+0000", "created_date":"2019-11-13T17:23:25+0000", "request_id":"bb36c8b4bce2c4-0198d59676189b0e344d1-00056689", "sum_initial":{ "amount":799, // Refund amount "currency":"EUR" // Refund currency code (same as initial payment currency) }, "sum_converted":{ "amount":799, "currency":"EUR" }, "code":"0", "message":"Success", "provider":{ "id":414, "payment_id":"", "endpoint_id":6 } }, "signature":"of8k9xerKSK4XL1QFaDH3p9Mh0CIcjmOwSwKJ7KLTZYO56lCv+f1M0Sf/7eg==" } ``` Here is an example in which a refund of `60.00 USD` for a one-time purchase is declined because of insufficient funds on merchant's account. This is indicated by the `3028` error returned by the payment platform. \(For more information about error codes, see [Handling operation processing information](en_platform_payment_info_codes.md).\) Note that the amount and status of the payment do not change. ```language-json { "project_id":239, "payment":{ "id":"payment7", "type":"purchase", // Payment type: one-time purchase "status":"success", // Payment status after refund decline "date":"2019-12-29T15:29:47+0000", "method":"card", "sum":{ "amount":6000, // Payment amount "currency":"USD" // Payment currency }, "description":"Thai massage session" // Payment description }, "account":{ "number":"431422******0056", "token":"14c24c8a5384b413f11b2956a82ddaeea609ea49", "type":"visa", "card_holder":"JUDY DOE", "expiry_month":"03", "expiry_year":"2023" }, "operation_description":"Error", // Refund reason "operation":{ "id":3869, "type":"reversal", // Operation type "status":"decline", // Payment status after refund decline "date":"2019-12-29T15:32:29+0000", "created_date":"2019-12-29T15:32:29+0000", "request_id":"713446e4b43-06bfc7eed42c4c854697846a-00059692", "sum_initial":{ "amount":6000, // Refund amount "currency":"USD" // Refund currency code (same as payment currency) }, "sum_converted":{ "amount":6000, "currency":"USD" }, "code":"3028", // Error code "message":"Insufficient funds on merchant balance", // Error description "provider":{ "id":120, "payment_id":"", "endpoint_id":120 } }, "signature":"of8k9xerKSK4XL1QFaDH3p9Mh0CIcjmOwSwKJ7KLTZYO56lCv+f1M0Sf/7eg==" } ``` ## Related links {#section_bgg_xhl_5jb .section} - [Payment processing](en_platform_payment_model.md)—general information about supported payment types and possible statuses. - [Methods](en_pm_about.md)—detailed information about payments using various payment methods. - [Handling callbacks](en_platform_callbacks.md#)—information about callbacks and how to use them. - [Handling operation processing information](en_platform_payment_info_codes.md)—error codes used by the payment platform. - [Monitoring and performing payments](en_dbl_payments.md#)—information about payments and operations performed by using Dashboard. **Parent topic:**[Gate](en_Gate_Integration_About.md) --- # Payouts {#en_Gate_payout .concept} An article about processing payouts via Gate. **Note:** This article covers processing payouts via Gate and describes requests and callbacks that are used in case of card payments. In addition, use the following materials to gain a fuller understanding of performing payouts: - [Payout](en_platform_payout_model.md)—an article in the section [Payment processing](en_platform_payment_model.md) that provides a general description of processing payouts in the Ecommpay payment platform and covers information about operations utilised to execute a payment of this type and statuses that are assigned to the payment and the operations performed within it. - articles of the [Payment methods](en_pm_about.md) section containing a description of performing payouts via Gate with the focus on the specific features of the payment method used and information about relevant requests and callbacks. ## Overview {#section_htd_ylv_cjb .section} *Payout* is a payment type which uses one request to make a one-time transfer of funds from merchant to customer. Basically, the payment platform performs payouts on demand \(one-time payments\)and P2P \(person-to-person\) payouts; though, you can implement bulk payouts by using Dashboard. In the latter case, you can have the required payouts generated automatically. For more information about bulk payouts, see [Monitoring and performing payments](en_dbl_payments.md#). Basically, payout initiation request contains payment instrument details. However,if you perform payout on a payment card you can perform payout by token that is associated with the payment card details. To enable this option, you need to perform an initial payment \(purchase\) to create a token.For more information about using tokens, see [Using tokens](en_Gate_Token.md). ## The payout workflow {#section_lsx_3jl_ggb .section} To perform a payout by using Gate the web service is required to do the following: 1. Send the payout request to the following endpoint `/v2/payment/{payment method}/payout[/token]`. 2. If necessary, complete the additional procedure of payment information submission that is used when any payment stakeholder requires additional information. The procedure is not currently supported for alternative payment methods.For more information, see [Submission of additional payment information](en_Gate_Clarification.md). 3. Receive the callback with payout results from the payment platform. The following diagram provides the information about the basic payout processing case \(without the completion of the additional procedure\). ![](images/en_uml_gate_payout.svg) 1. A customer initiates a payout. 2. The web service sends the payout request by using Gate to the payment platform. 3. The payment platform receives the payout request. 4. The payment platform performs the initial request processing that includes validation of the required parameters and signature. 5. The payment platform sends to the web service the response with request receipt confirmation and correctness check result. 6. The payment platform performs the internal payment request processing and sends it to the payment environment.If you process the payout by using payment card, the payment environment is a bank service. If you process the payout by using alternative payment instrument, one is the payment system service. 7. The payout is processed on the payment service side. 8. The payment platform receives the payout result notification. 9. The payment platform sends the callback to the web service. 10. The customer receives the payment result from the web service. The sections that follow discuss in more details the request format and the parameters to be used in requests for payouts to payment cards, as well as provide information about the format of callbacks which contain payout results. Information about possible statuses of this payment type can be found in [the corresponding article](en_platform_payment_model.md). ## Request format {#section_t11_mfk_1jb .section} There are several things you need to consider when using payout requests to payment cards: 1. You perform payout by sending the request by using POST \(HTTP\) method to one of the following endpoints: - when making a payout by card number—[/v2/payment/card/payout](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-payout), - when making a payout by the token that is associated with payment card details—[/v2/payment/card/payout/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-payout-token), - when making a P2P payout—[/v2/payment/individual/payout](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-individual-payout). 2. The following objects and parameters must be specified in the request: - Object `general`—general request identification information: - `project_id`—the project ID obtained from Ecommpay - `payment_id`—payment ID unique within the merchant project - `signature`—signature created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#) - Object `customer`—customer information: - `id`—the ID of the customer within the merchant project - `first_name`—customer first name - `middle_name`—customer middle name or patronymic - `last_name`—customer last name - `ip_address`—IP address **Note:** The first name, the middle name \(or patronymic\), and the last name of the customer must be specified for all cards with the exception of those issued in the Russian Federation. For the latter, passing these parameters is not required, but in certain cases not providing them may lead to declined payments. To increase the probability of payment acceptance by issuers, it is recommended to pass both the first and the last name of the payout recipient, or at least one of these parameters. For up-to-date information about specifying the first name, the patronymic, and the last name for payouts to cards issued in Russia, contact your Ecommpay account manager. The first name, the middle name \(or patronymic\), and the last name must be specified in Basic Latin characters for all cards with the exception of CUP cards for which this information must be provided in Chinese characters. In case of payouts that originate from physical persons and that are processed as part of the programs supported for the Mastercard MoneySend service, it is required that the first and last names of the payout recipient are specified in the `recipient` object. Therefore, it is not necessary to specify this information in the `customer` object \([more](en_Gate_payout.md#li_ucr_fj5_tqb)\). This requirement applies to all cards regardless of where they were issued. - Object `payment`—payment information: - `amount`—payout amount in minor units - `currency`—payout currency in the ISO-4217 alpha-3 format - `cryptocurrency_type`—the indicator that specifies the type of the cryptocurrency, required for Mastercard and Visa payments involving cryptocurrencies. This parameter should be assigned one of the following values: - `cbdc`—a central bank digital currency or tokenized deposit issued by a central bank, reserve bank, or other national monetary authority; - `stablecoins_fiat_backed`—a fiat-backed digital asset with reserves held by a licensed financial institution; - `native_tokens`—a digital currency native to a specific blockchain, required for transactions within its network, including fee payments; - `other`—a non-fiat digital asset that does not fit other types or cannot be classified at the time of transaction initiation. 3. The request must contain the following information about the payment card which will be used in the payout: - For a payout by card number—the card number in the `pan` parameter of the `card` object. In case of global payouts, together with the card number you may need to provide the expiration date and the name of the cardholder in the `year`, `month`, and `card_holder` parameters of the object `card`. To learn more about global payouts, contact your Ecommpay account manager. - For a payout by token—the token of the card received from Ecommpay in the `token` parameter. 4. In the case of a payout to any Visa card, the request should contain the date of birth of the sender, specified in `DD-MM-YYYY` format in the `day_of_birth` parameter in the `sender` object. 5. In the case of a payout to a Visa card issued in Canada, the request must contain the `recipient` object with the payout recipient's address data: - `country`—recipient's country code in ISO 3166-1 alpha-2 - `city`—recipient's city - `address`—recipient's address - if the specified country code is [CA](references/en/countries/CA.md) or [US](references/en/countries/US.md), also pass the `state` parameter that provides information about the recipient's state, province, or any other region 6. In the case of a payout processed as part of the Visa Money Transfer program to a card issued in Brazil or Qatar, the request must contain the sender's phone number in the `phone` parameter of the `sender` object. 7. In the case of a payout to a Mastercard, the value of the `address` parameter passed in the `customer` object cannot exceed 50 characters. 8. In the case of a payout that originates from a physical person and that is processed as part of the programs supported for the Mastercard MoneySend service, the request must contain the information about the payout recipient's name in the `first_name` and `last_name` parameters of the `recipient` object and the information about the payout sender in the `sender` object: - number of the sender's payment instrument—`pan` for the sender's card or `wallet_id` for the sender's electronic wallet - `first_name`—sender's first name - `last_name`—sender's last name - `address`—sender's address - `city`—sender's city - `zip`—sender's postal code - `country`—sender's country code in ISO 3166-1 alpha-2 - if the specified country code is [CA](references/en/countries/CA.md) or [US](references/en/countries/US.md), also pass the `state` parameter that provides information about the sender's state, province, or any other region 9. In the case of a P2P payout it is recommended to specify the sender data: - `first_name`—first name - `last_name`—last name, - `citizenship`—citizenship - `residence`—country of residence - `birthplace`—place of birth - Object `billing`—sender billing address information 10. If required, you can also add any other additional parameters and objects Gate supports. Thus, to perform a payout on a payment card, the correct payout request must include project and payment IDs, signature, the ID and IP-address of the customer, amount and currency of the payout, as well as the number or token of the card \(for crediting\), as shown in the following example: ```language-json { "general": { "project_id": 874, "payment_id": "1553840734526111", "signature": "1wR1YgDoDlJppOdLzFOFKY4YonbWmspbFh7x1o1ut5PxxTIJfQ==", }, // Card number when payout by the card number "card": { "pan": "5413330000000019" }, "customer": { "id": "1", "ip_address": "185.123.193.224" }, "payment": { "amount": 15000, "currency": "EUR" }, // Card token when payout by the token "token": "pkmawa3khb7wninntq8g8q3592fjjxwvzfebwbegqkl1c16akpgo6sgxac6wulz7" } ``` ```language-json { "general": { "project_id": 100, "payment_id": "Payment 12", "signature": "2tlMuYxLW9Yu6RETr8pdCfmi0UPE8euD+2AbrQgJgu...==" }, "card": { "pan": "4242424242424242", "year": 2020, "month": 11 }, "customer": { "ip_address": "127.0.0.1", "id": "New", "phone": "999123456", "first_name": "John", "middle_name": "Jr", "last_name": "Jonson", "datetime": "2017-10-04T19:06:31+05:00", "birthplace": "Manchester", "identify": { "doc_number": "4666 123456", "doc_type": "Passport", "doc_issue_date": "20.12.2012", "doc_issue_by": "12346" }, "billing": { "country": "GB", "city": "London", "address": "Level st, 23", "postal": "112233" }, "day_of_birth": "05-06-1981" }, "sender": { "phone": "39999999999", "first_name": "Jack", "middle_name": "Willy", "last_name": "Jackson", "datetime": "2018-12-05T19:06:31+05:00", "birthplace": "Manchester", "residence": "BL", "citizenship": "LV", "identify": { "doc_number": "1234 654321", "doc_type": "Passport", "doc_issue_date": "07-08-2014", "doc_issue_by": "23456" }, "billing": { "country": "GB", "city": "London", "address": "Level st, 25", "postal": "406879" }, "day_of_birth": "07-08-1993" }, "payment": { "amount": 5000, "currency": "GBP" } } ``` ## Callback format {#section_wsx_3jl_ggb .section} The standard format for callbacks is used to deliver payout results. For more information, see [Handling callbacks](en_platform_callbacks.md#). The following is the example of a callback with an information about successful `100.00 USD` payout made to the card number `553691******0802` of the `customer_10` customer in the `874` project. ```language-json { { "project_id": 874, "payment": { "id": "3013", "type": "payout", "status": "success", "date": "2019-06-24T11:08:49+0000", "method": "card", "sum": { "amount": 10000, "currency": "USD" }, "description": "" }, "account": { "number": "541333******0019" }, "customer": { "id": "customer_10" }, "operation": { "id": 14, "type": "payout", "status": "success", "date": "2019-06-24T11:08:49+0000", "created_date": "2019-06-24T11:07:42+0000", "request_id": "71228f54d21e776a481", "sum_initial": { "amount": 10000, "currency": "USD" }, "sum_converted": { "amount": 10000, "currency": "USD" }, "provider": { "id": 1496, "payment_id": "60-1c6072de6000", "date": "2019-06-24T11:08:47+0000", "auth_code": "" }, "code": "0", "message": "Success" }, "signature": "+GTEzb3Xw4A9Ap8q/LE8TyyJM+TaK4UzSgifLxgB6c9TSeb/peLxw==" } } ``` The following example of callback is for a payout rejected due to the maximum payout limit being exceeded. ```language-json { { "project_id": 874, "payment": { "id": "3013", "type": "payout", "status": "decline", "date": "2019-06-24T11:08:49+0000", "method": "card", "sum": { "amount": 10000, "currency": "USD" }, "description": "" }, "account": { "number": "541333******0019" }, "customer": { "id": "customer_10" }, "operation": { "id": 14, "type": "payout", "status": "decline", "date": "2019-06-24T11:08:49+0000", "created_date": "2019-06-24T11:07:42+0000", "request_id": "71228f54d21e776a481", "sum_initial": { "amount": 10000, "currency": "USD" }, "sum_converted": { "amount": 10000, "currency": "USD" }, "provider": { "id": 1496, "payment_id": "60-1c6072de6000", "date": "2019-06-24T11:08:47+0000", "auth_code": "" }, "code": "3104", "message": "Payment Constraint Invalid Payout Amount" }, "signature": "+GTEzb3Xw4A9Ap8q/LE8TyyJM+MEXXja28RXtr8v2EITaK4UzSg...==" } } ``` **Parent topic:**[Gate](en_Gate_Integration_About.md) --- # Payment instrument verification {#en_gate_account_verification .concept} An article about verifying a payment instrument via Gate by debiting a zero amount or placing a hold on funds. **Note:** This article covers payment instrument verification via Gate and describes requests and callbacks that are used in case of card payments. In addition, use the following materials to gain a fuller understanding of payment instrument verification: - [Payment instrument verification](en_platform_account_verification_model.md)—an article in the section [Payment processing](en_platform_payment_model.md) that provides a general description of performing payment instrument verification in the Ecommpay payment platform and covers information about statuses that can be used in the process. - articles of the [Payment methods](en_pm_about.md) section containing a description of payment instrument verification via Gate with the focus on the specific features of the payment method used and information about relevant requests and callbacks. To find out whether you can use payment instrument verification, refer to your Ecommpay account manager. ## Overview {#section_nmn_ctf_fjb .section} Payment instrument verification is a payment type in which the customer card or account is validated by either transferring a dummy \(zero\) amount from customer to merchantor by authorizing a specific amount \(non-zero\) on the customer card or account and then voiding the transfer or the authorization. The authorization amount can be changed on merchant's request. Normally, the authorized amount is released shortly after the operation, but in some instances the authorized amount can be held up to 45 days. You can use verification to register any subscriptions without debiting funds for the first \(trial\) period or you can use it before perform a payout. For more information about COF purchases, see [Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md).Payment instrument verification functionality can also be relevant for processing MO/TO \(Mail Order/Telephone Order\) payments which imply that customers provide payment card details over the phone, by email, or other means of communication. For more information about MO/TO payments, see [MO/TO payment processing](en_Gate_moto.md). For additional fraud and chargeback risk assessment, you can use the capability of cardholder name verification together with the card verification \([details](en_gate_cardholder_name_verification.md)\). ## The payment instrument verification workflow {#section_qmn_ctf_fjb .section} To perform the payment instrument verification by using Gate the web service is required to do the following: 1. Send the request by using the POST \(HTTP\) method to the endpoint `/v2/payment/\{payment method\}/account_verification[/token]`. 2. If necessary, complete the additional procedures: - *3‑D Secure authentication*. This authentication is intended to provide security to online payments with payment cards. For more information on the authentication workflow, as well as request and callback formats, see [3‑D Secure authentication](en_gate_payment_3ds.md#). - *Additional payment information submission*. This procedure is intended for cases, where the initial request did not contain the information necessary for any payment process stakeholders. For more information on this procedure, see [Submission of additional payment information](en_Gate_Clarification.md). 3. Receive the callback with verification results from the payment platform. The following diagram outlines the basic case of verification workflow \(without the completion of the additional procedure\). ![](images/en_gate_account_verification.svg) 1. A customer enters the payment instrument details on the web service side. 2. The web service sends the payment instrument verification request by using Gate to the payment platform. 3. The payment platform receives the verification request. 4. The payment platform performs the initial request processing that includes validation of the required parameters and signature. 5. The payment platform sends to the web service the response with request receipt confirmation and correctness check result. 6. The payment platform performs the internal payment request processing and sends it to the payment environment. If you process the payment card verification, the payment environment is a bank service.If you process the alternative payment instrument verification, one is the payment system service. 7. The payment instrument verification is processed. 8. The payment platform receives the verification result notification. 9. The payment platform sends the callback to the web service. The sections that follow discuss in more details the request format and the parameters to be used in requests for payment card verification, as well as provide information about the format of callbacks the verification results. Information about possible statuses of this payment type can be found in [the corresponding article](en_platform_payment_model.md). ## Request format {#section_xmn_ctf_fjb .section} There are several things you need to consider when using payment card verification requests: 1. Send the request by using POST \(HTTP\) method to one of the following endpoints: - when performing verification by card number—[/v2/payment/card/account\_verification](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification) - when performing verification by the token that is associated with payment card details—[/v2/payment/card/account\_verification/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification-token) 2. The following objects and parameters must be specified in the request: - Object `general`—general request identification information: - `project_id`—the project ID obtained from Ecommpay - `payment_id`—payment ID unique within the merchant project - `signature`—signature created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#) - Object `customer`—customer information: - `ip_address`—IP address - `id`—the ID of the customer within the merchant project - Object `payment`—payment information: - `amount`—payment amount, the value is 0 - `currency`—payment currency in the ISO-4217 alpha-3 format 3. The request must contain the following customer's payment card information: - when passing complete card credentials—the following data in the `card` object: - `pan`—card number - `year`—year of expiration date - `month`—month of expiration date - `card_holder`—name of the cardholder, passed if this parameter is required for the specific project \(the name must be spelled as specified on the card; note that if you want to make this parameter optional instead of required, it can only be done upon consultation with your account manager which includes examination and assessment of associated risks\) - `cvv`—card verification code \(as indicated on the card\).This parameter is not necessary for processing of MO/TO payments. For more information, see [MO/TO payment processing](en_Gate_moto.md). - when passing the token—token received from Ecommpay in the `token` parameter and the card verification code in the `cvv` parameter\(this parameter is not necessary for processing of MO/TO payments. For more information, see [MO/TO payment processing](en_Gate_moto.md)\). 4. If required, you can also add any other additional parameters and objects Gate supports. **Note:** The payment amount must be zero. Thus, the correct payment card verification request must include project and payment IDs, signature, the customer's payment card details, the ID and IP-address of the customer, as shown in the following example: ```language-json { "general":{ "project_id":874, "payment_id":"15538406111", "signature":"1wR1YgD5PxxTIJfQ==" }, "customer":{ "ip_address":"185.123.193.224", "id":"customer_10" }, "payment":{ "amount":0, "currency":"USD" }, //when indicating complete card credentials: "card":{ "pan":"4314220000000056", "year":2021, "month":9, "card_holder":"John Smith", "cvv":"123" }, //when indicating the token of a stored payment card: "token":"f365bb1729f9b72fd9c79f3becc679f29c3e35c91d070d15654", "cvv":"123" //when COF payment registration is made: "recurring":{ "register":true } } ``` ## Callback format {#section_fnn_ctf_fjb .section} The standard format for callbacks is used to deliver payout results. For more information, see [Handling callbacks](en_platform_callbacks.md#). The following is the example of a callback with information about the successful verification of the `431422******0056` card of the customer `customer_10` in the `874` project. The card is verified and is registered for COF purchases. ```language-json { "project_id":874, "payment":{ "id":"15538406111", "type":"account_verification", "status":"success", "date":"2019-09-10T13:45:59+0000", "method":"card", "sum":{ "amount":0, "currency":"EUR" }, "description":"Add the card" }, "account":{ "number":"431422******0056", "token":"844f84f3bdfaf2ddf006c96ffaddc09394c5d0e158f", "type":"visa", "card_holder":"JOHN SMITH", "id":8861226, "expiry_month":"09", "expiry_year":"2021" }, "customer":{ "id":"customer_10" }, "recurring":{ "id":10505, "currency":"EUR", "valid_thru":"2022-09-30T00:00:00+0000" }, "operation":{ "id":4314220000000056, "type":"account verification", "status":"success", "date":"2019-09-10T13:45:59+0000", "created_date":"2019-09-10T13:45:57+0000", "request_id":"5cb898347e62b2c1-52dac6c8c", "sum_initial":{ "amount":0, "currency":"EUR" }, "sum_converted":{ "amount":0, "currency":"EUR" }, "provider":{ "id":120, "payment_id":"306449667", "date":"2019-09-10T13:45:59+0000", "auth_code":"188591", "endpoint_id":120 }, "code":"0", "message":"Success" }, "signature":"P9g0U+eF2QWs2A==" } ``` The following example of callback is for a card payment verification that is rejected by the payment system without explanation. ```language-json { "project_id":874, "payment":{ "id":"15538406111", "type":"account_verification", "status":"decline", "date":"2019-09-16T06:06:53+0000", "method":"card", "sum":{ "amount":0, "currency":"EUR" }, "description":"Add the card" }, "account":{ "number":"431422******0056", "type":"visa", "card_holder":"JOHN SMITH", "expiry_month":"09", "expiry_year":"2021" }, "customer":{ "id":"customer_10" }, "operation":{ "id":4314220000000056, "type":"account verification", "status":"decline", "date":"2019-09-16T06:06:53+0000", "created_date":"2019-09-16T06:06:47+0000", "request_id":"9120271eb02-83e0e70fc0a0a3c1b4d", "sum_initial":{ "amount":0, "currency":"EUR" }, "sum_converted":{ "amount":0, "currency":"EUR" }, "provider":{ "id":120, "payment_id":"308822001", "date":"2019-09-16T06:06:49+0000", "auth_code":"", "endpoint_id":120 }, "code":"10100", "message":"Declined by external provider" }, "signature":"P9g0U+eaZ9EeNiWiaQWs2A==" } ``` **Parent topic:**[Gate](en_Gate_Integration_About.md) --- # Auxiliary procedures {#en_gate_procedures} Articles about auxiliary procedures that can be required during processing specific payments via Gate. This section provides the information about the procedures that can be required for processing certain payments. - [3‑D Secure authentication](en_gate_payment_3ds.md#)—about customer authentication with the use of protocol 3‑D Secure 2 for ensuring secure payment processing. - [3‑D Secure authentication on merchant side](en_gate_merchant_3ds.md)—about an additional variant of customer authentication with the use of the 3‑D Secure protocol on the merchant web service side. - [Authentication on merchant's request](en_gate_payment_merch_auth.md)—about the procedure of additional customer authentication that can be used as an alternative to the 3‑D Secure authentication and is performed upon the merchant's request. - [Using the Address Verification Service](en_Gate_avs.md)—about the procedure of verifying the customers' postal codes and addresses to ensure secure processing of payments with the use of the American Express, Mastercard, and Visa cards. - [Using the Verification of Payee service](en_verification_of_payee.md#)—about the procedure of verifying the customers' names when they issue a request to receive the funds, in order to ensure that bank transfers using the SEPA payment scheme comply with the European Union Instant Payments Regulation. - [Submission of additional payment information](en_Gate_Clarification.md)—about the procedure of providing additional data that can be requested by payment systems in separate cases. - [Currency conversion](en_Gate_Conversion.md)—about processing payments in different currencies for the customer and the merchant with the conversion involved. - **[3‑D Secure authentication](en_gate_payment_3ds.md#)** An article about primary workflows of authenticating customers with the use of the 3‑D Secure protocol for processing card payments via Gate, performed through the Ecommpay platform. - **[3‑D Secure authentication on merchant side](en_gate_merchant_3ds.md)** An article about an additional option of authenticating customers with the use of the 3‑D Secure protocol for processing card payments via Gate, performed through third-party solutions and initiated by the merchant. - **[Authentication on merchant's request](en_gate_payment_merch_auth.md)** An article about the procedure of authenticating customers upon merchant's request that can be used as an alternative to the 3‑D Secure authentication for processing card payments via Gate. - **[Using the Address Verification Service](en_Gate_avs.md)** An article about the procedure of verifying customers' postal codes and addresses for processing American Express, Mastercard, and Visa payments via Gate. - **[Using the Verification of Payee service](en_verification_of_payee.md#)** An article about the procedure of verifying customers' names when payouts to bank accounts using the SEPA payment scheme are initiated via Gate. - **[Submission of additional payment information](en_Gate_Clarification.md)** An article about the procedure of specifying additional data that can be requested by payment systems during payment processing via Gate. - **[Currency conversion](en_Gate_Conversion.md)** An article about processing payments via Gate in different currencies with currency conversion. **Parent topic:**[Gate](en_Gate_Integration_About.md) --- # 3‑D Secure authentication on merchant side {#en_gate_merchant_3ds} An article about an additional option of authenticating customers with the use of the 3‑D Secure protocol for processing card payments via Gate, performed through third-party solutions and initiated by the merchant. ## General information {#section_i3t_kkq_qmb .section} Customer 3‑D Secure authentication can be performed either on the Ecommpay payment platform side or on the merchant side. If authentication is performed on the merchant's side, the authentication result must be sent to the payment platform in order to make a payment. Repeated authentication on the payment platform side will not occur. To enable the capability, contact technical support \([support@ecommpay.com](mailto:support@ecommpay.com)\). ## Sending the 3‑D Secure authentication result {#section_vfr_mkq_qmb .section} Information about the 3‑D Secure authentication result is passed in the `authentication_data` object in a request for performing a one-time purchase, including purchases that use a token or saved card data, or a request for card verification. Data is passed in the following parameters: |Parameter|Type|Mandatory|Description| |---------|----|---------|-----------| |`cavv`|string|Mandatory if `authentication_status=Y or A`|Cardholder authentication verification value \(base64 encoded, 20 bytes in a decoded form\)| |`ds_operation_id`|string|Mandatory if `threeds_version=3ds_2`|The unique operation identifier assigned by the Directory Servers| |`eci`|string|Mandatory if `authentication_status=Y or A`|The electronic commerce indicator, for more information, see the section [Electronic Commerce Indicators](en_ECI_codes.md)| |`threeds_version`|string|Optional|Indicator of the 3‑D Secure authentication:- `3ds_2` - `non_3ds` | |`threeds_full_version`|string|Optional|The version of the 3‑D Secure protocol, for example 2.3.1| |`xid`|string|Mandatory|Transaction identifier resulting from authentication processing \(base64 encoded, 20 bytes in a decoded form\)| |`authentication_status`|string|Mandatory, except if `enrollement_status=N or U`|Cardholder authentication status. Possible values are: - `Y`—the cardholder was successfully authenticated by their card issuer - `A`—the cardholder authentication was attempted - `U`—the card issuer was unavailable during the authentication attempt | |`authentication_status_reason_code`|string|Optional|Code of the authentication status reason| |`authentication_flow`|string|Optional|Scenario of 3‑D Secure authentication- `Frictionless`, - `Challenge` | ``` { "general":{ "project_id":200, "payment_id":"id_15514400636", "signature":"PJkV8ej\/UG0Di8hTng6JvC7vQsaC6tajQ...==" }, "card":{ "pan":"some_string", "year":2025, "month":12, "card_holder":"JOHN JOHNSON", "cvv":"some_string" }, "customer":{ "id":"123", "ip_address":"217.1.1.0" }, "payment":{ "amount":1000, "currency":"EUR" }, "authentication_data":{ "cavv":"kEMQyiH/ASySYhP1hAErbWFO+mih", "ds_operation_id":"f780a79f-a5e1-44d8-bfa3-5f89432fdb79", "eci":"06", "threeds_version":"3ds_2", "xid":"MDAwMDAwNzYxODEwMDAwMDE3MDE=", "authentication_status":"A", "authentication_flow":"Frictionless", "threeds_full_version":"2.3.1", "authentication_status_reason_code":"01" } } ``` ## Related topics {#section_xsx_3jl_ggb .section} The following topics can be useful when implementing payments through Gate: - [Interaction concepts](en_gate_interaction_organisation.md#) - [Signature generation and verification](en_platform_signature.md#) - [Payment processing](en_platform_payment_model.md) - [Handling operation processing information](en_platform_payment_info_codes.md) - [3‑D Secure authentication](en_gate_payment_3ds.md#) **Parent topic:**[Auxiliary procedures](en_gate_procedures.md) --- # Authentication on merchant's request {#en_gate_payment_merch_auth} An article about the procedure of authenticating customers upon merchant's request that can be used as an alternative to the 3‑D Secure authentication for processing card payments via Gate. ## General information {#section_zq3_2q2_zhb .section} Customer authentication performed by the provider on merchant's request is intended to provide additional security for online payments by payment cards. Such authentication is usually used as a replacement for 3‑D Secure in addition to it. This can be appropriate when the 3‑D Secure authentication is not reliable enough, e.g. when issuers use outdated ways of authentication. Customer authentication on merchant's request implies submitting the validation code, which is contained in the information about the debiting of customer funds. The information is received by the customer in a SMS or a bank statement. The payment platform supports authentication on merchant's request only for some providers, to enable this authentication a merchant project has to be configured. To do this, contact Ecommpay technical support at [support@ecommpay.com](mailto:support@ecommpay.com). When performing a customer authentication by the payment system on merchant's request, the merchant web service is required to do the following: - receive a callback from the payment platform containing the information about the change of payment status to `awaiting merchant auth`. - obtain user consent. - send the authentication request. - receive the validation code from the customer. - send the request containing the validation code to the payment platform. Detailed information on authentication on merchant's request is provided in the sections that follow. ## Workflow {#section_pjt_5jb_v3b .section} Authentication on merchant's request is possible when performing one-step and two-step purchases by payment cards. *Information* about the necessity of such authentication is contained in callbacks. As a general rule, after receiving a callback a response must be sent to the payment platform. Callbacks contain information about the change of payment status to `awaiting merchant auth`. The following scenario must be implemented on the web service side in order to successfully *react* to such callbacks: the web service must *obtain* the customer's consent to the authentication, *send* the authentication request to the payment platform, *receive* the validation code from the customer, *send* the request containing code to the payment platform to continue payment processing. The time-out value for this request is unlimited, taking into account the results of authentication. The overall time of payment processing may not exceed the maximum allowed amount, which is set on the provider's side. If the payment is not successful or declined during this time, it automatically assumes the `decline` status. After the payment platform receives the request containing the validation code, the payment processing continues. ![](images/en_gate_scheme_merchant_auth.svg) 1. The payment is processed in the payment platform. 2. The payment platform sends the callback to the web service informing about the necessity of authentication. 3. The customer is redirected to the web page containing the information on the authentication. 4. The user agrees to the authentication. 5. The web service sends the request for authentication initiation to the specified Ecommpay URL. 6. The payment platform receives the request. 7. The payment platform processes the request. 8. The payment platform sends the response with request receipt confirmation and correctness check result to the web service. 9. The payment platform sends the request for authentication initiation request to the provider service. 10. The provider processes the request and sends the validation code to the customer. 11. The customer enters the validation code. 12. The web service sends the request for authentication completion and continuation of payment processing to the specified Ecommpay URL. 13. The payment platform receives the request. 14. The payment platform processes the request. 15. The payment platform sends the response with request receipt confirmation and correctness check result to the web service. 16. The web service sends the request for authentication completion and continuation of payment processing to the provider service. The sections that follow discuss in more details the request and callback formats. For general information on how to use the API, see [Interaction concepts](en_gate_interaction_organisation.md#). ## Format of callback informing about the necessity of authentication {#section_gzw_wbd_w3b .section} The information about the necessity of authentication is contained in a callback, which uses a standard format. For more results, see [Handling callbacks](en_platform_callbacks.md#). The following is the example of a callback, with information about the payment and operation assuming the `awaiting merchant auth` status before the payment processing request is received. ```language-json { "project_id":42, "payment":{ "id":"456789", "type":"purchase", "status":"awaiting merchant auth", // Payment status "date":"2019-02-20T15:33:11+0000", "method":"card", "sum":{ "amount":400000, "currency":"USD" }, "description":"" }, "account":{ "number":"431422******0056", "type":"visa", "card_holder":"JOHN SMITH", "expiry_month":"08", "expiry_year":"2025" }, "customer":{ "id":"customer_12" }, "operation":{ "id":171200003265, "type":"sale", "status":"awaiting merchant auth", // Operation status "date":"2019-02-20T15:33:11+0000", "created_date":"2019-02-20T15:33:02+0000", "request_id":"617c2626f873151a1cf5873ceb7cca0ade292ee-646d...ec", "sum_initial":{ "amount":400000, "currency":"USD" }, "sum_converted":{ "amount":400000, "currency":"USD" }, "provider":{ "id":4, "payment_id":"3301571985", "auth_code":"", "endpoint_id":4 }, "code":"9999", "message":"Awaiting processing", "eci":"06" }, "signature":"v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" } ``` ## Format of request for authentication initiation {#section_r2m_h52_zhb .section} To initiate an authentication on merchant's request a request must by sent to the payment platform by using the POST \(HTTP\) request to the following endpoint [/v2/payment/card/merchant\_auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-merchant-auth). This request must include the `general` object, containing general request identification information and request type indicator: - `project_id`—the project ID obtained from Ecommpay - `payment_id`—payment ID unique within the project - `type`—indicator of request type, must have the `start` value - `signature`—signature created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#) Thus a correct request must include the project and payment IDs, indicator of request type \(`start`\) and signature. ```language-json { "general": { "project_id": 42, "payment_id": "456789", "type": "start", "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" } } ``` ## Format of request for continuation of payment processing {#section_mm2_xv1_v3b .section} Taking into account the result of authentication, to continue payment processing a request using the POST \(HTTP\) method must be sent to the endpoint [/v2/payment/card/merchant\_auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-merchant-auth). The request must contain the following objects and parameters: 1. Object `general`—general request identification information: - `project_id`—the project ID obtained from Ecommpay - `payment_id`—payment ID unique within the project - `type`—indicator of request type, must have the `finish` value - `signature`—signature created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#) 2. `confirmation_code`—validation code received from the customer. Thus a correct request must include the project and payment IDs, indicator of request type \(`finish`\), signature and validation code. ```language-json { "general": { "project_id": 42, "payment_id": "456789", "type": "start", "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" }, "confirmation_code": "835" } ``` **Parent topic:**[Auxiliary procedures](en_gate_procedures.md) --- # Using the Address Verification Service {#en_Gate_avs .concept} An article about the procedure of verifying customers' postal codes and addresses for processing American Express, Mastercard, and Visa payments via Gate. Address Verification Service \(AVS\) is a service that allows you to check whether a customer who makes a payment by a bank card is the actual cardholder. The AVS check is performed by matching the address specified by a customer while performing a payment with the cardholder address according to the bank card Issuer. AVS verification is mandatory for payments with Visa and Mastercard cards performed in the UK, and optional in the USA, Australia, Canada and New Zealand. For American Express, AVS verification is mandatory in the USA and Canada and optional in other countries.Therefore, you may be required to add more mandatory parameters in the request for payment: customer postal code in the `avs_post_code` parameter and customer address in `avs_street_address`. You can submit these parameters in a additional parameters request. For more information, see [Submission of additional payment information](en_Gate_Clarification.md). If the data is missing, fails to pass the validation or is empty, you will receive a message with the corresponding decline code. The result of the AVS verification is passed in the `avs_result` callback parameter. There are two schemes of work with AVS: sending the AVS parameters in each payment request or sending the AVS parameters in a clarification request, if AVS is enabled for the country of the card Issuer in the project settings. **Note:** The requirement to provide AVS parameters persists even if the payment is made by a token or a saved bank card. ## Results of checking with AVS {#section_gq3_n12_pfb .section} Below is a table of possible codes that can be returned, with additional information and descriptions for them. |Code|Value|Description| |----|-----|-----------| |W, Z|Partial match|Post code matches, but street address does not| |A|Partial match|Street address matches, but post code does not| |X, Y|Exact match|Address and post code match| |N|No match|Street address and post code do not match| |S, U|Address information unavailable.|Address information is unavailable for this account or an issuing bank does not support the AVS| |R|System unavailable|System is unavailable at the moment, retry| |VISA|A, N, R, U, Y, Z| |MasterCard|A, N, R, S, U, W, X, Y, Z| |American Express|A, N, R, S, U, Y, Z| **Parent topic:**[Auxiliary procedures](en_gate_procedures.md) --- # Submission of additional payment information {#en_Gate_Clarification .concept} An article about the procedure of specifying additional data that can be requested by payment systems during payment processing via Gate. ## Overview {#section_m3x_r1k_m3b .section} Normally, when performing payment, mandatory parameters that are required to initiate the payment provide enough information. A payment system or the payment platform may require your web service to submit some optional parameters that otherwise are not required, this may be due to regional or country-specific requirements or additional fraud testing procedures. The additional payment information submission procedure implemented on the payment platform allows you to handle these cases. When performing the procedure, the payment platform require your web service to provide additional mandatory data and waits for the data to be submitted. Also, the payment platform is flexible as to the ways this additional information is requested and accepted from the web service. Additional information the payment platform requests typically concerns the customer and the payment method. If the payment is performed by using payment cards, the payment platform may request the parameters of the `avs_data`—Address Verification Service requirements, [AVS](en_Gate_avs.md)—or any parameters of the `customer` objects.If the payment is performed by using alternative payment method, the payment platform may request any optional parameters of the initial payment request. If you provide all the mandatory and optional parameters in each payment initiation request, you will never be required to submit additional information. Otherwise, you should implement the scenario in which during the payment processing, the payment platform requests additional information and you submit the information. The following sections provides more details about the workflow. ## The workflow {#section_k4j_qjk_m3b .section} The payment platform or provider, as well as a payment system may require additional payment information. There are two ways the payment platform requests any additional information:*callbacks and responses*. Normally, the payment platform requests additional data in callbacks; in which case you are not required to issue any additional requests. Alternatively, you can issue a request for payment status and have the payment platform respond with a response that specifies what additional information is required. Then, the web service needs to generate and send *the request* that contains additional information. After the payment platform discovers that additional information is required, it waits for submission of the additional information for 30 minutes. If the payment platform does not receive the request with the additional information within these 30 minutes, the payment is automatically declined. Although, your web service can resend the request with partial or even empty additional data, in this case, the 30-minutes time-out is reset. This way, you can prolong payment processing, if you need more time to collect all the additional data. Note though, that you can not prolong payment processing beyond the payment processing threshold. *The parameter set* inside the request body may vary—you can specify all the parameters, part of the parameters, or no parameters at all, but you always must specify the `additional_data` object inside the request. If the request the payment system receives does not contain the object, the payment system considers the request incorrect and sends an error response. If the request contains all the required parameters, the payment platform responds with the `200 OK` response. If the request contains the `additional_data` object with no the required parameters or only a part of required parameters, the payment platform responds with a callback or a response that lists with the rest of the required parameters. As soon as the payment platform obtains all the required information, the payment platform continues to process payment. ![](images/en_clarification_uml.svg) During interaction with the payment platform, your web service is required to do the following: 1. Receive a callback or a response with the `clarification_fields` object that lists the required parameters. 2. Send the request that contains all the required objects and parameters including the `additional_data` object *and* signature to the [/v2/payment/clarification](https://api-developers.ecommpay.com/api-specification/additional-information-submission/post-v2-payment-clarification) endpoint by using POST HTTP method. 3. Receive and handle the `200 OK` response. The payment platform responds with the `200 OK` response when payment platform receives all the required parameters with correct values. If not, the payment platform requests additional data again starting at *step 1*. The information about the format of a callback and a response that may list with parameters and the request format are covered in greater details below. ## Callback and response format {#section_oyf_d4j_m3b .section} There are two ways the payment platform requests any additional information: callbacks and responses to a request for payment status. *The callbacks*that the payment platform sends to request additional payment information use the standard format described in [Handling callbacks](en_platform_callbacks.md#). Note that in this case, the callbacks contain the `clarification_fields` object that lists with required parameters.The following is the example of the callback that is used to request the customer postal code and address that AVS requireswhen payment processing by using payment card. ```language-json POST /notify/success HTTP/1.1 Content-Length: 1237 User-Agent: GuzzleHttp/6.3.3 curl/7.47.0 PHP/7.0.32-0ubuntu0.16.04.1 Content-Type: application/json Host: example.com { "sum_request": { "amount": 45000, "currency": "USD" }, "request_id": "80bdc0831c3f8e1", "payment": { "id": "", "method": "card", "date": "2019-07-29T11:19:33+0000", "result_code": "9999", "result_message": "Awaiting processing", "is_new_attempts_available": false, "attempts_timeout": 0, "provider_id": 3 }, "sum_real": { "amount": 45000, "currency": "USD" }, "status": "awaiting clarification", // The payment status "customer": { "id": "4314220000000056" }, "account": { "number": "431422******0056", "type": "visa", "card_holder": "JUDY DOE", "expiry_month": "03", "expiry_year": "2021" }, "clarification_fields": { // The additional information requested "avs_data": [ "avs_post_code", "avs_street_address" ] }, "general": { "project_id": 11, "payment_id": "EPr-bf14", "signature": "99q4lpCEuNpxp3ugvxF1qPbinWUIwNSLaxcVbF0A==" }, "description": "", "operations": [ { "id": 7282148104130, "type": "sale", "status": "awaiting clarification", "date": "2019-07-29T11:19:33+0000", "processing_time": null, "sum": { "amount": 45000, "currency": "USD" }, "code": "9999", "message": "Awaiting processing" } ] } ``` *The responses* that the payment platform sends to request additional payment information use the same format that the callbacks use.The following is the example of the response to the request that a merchant web service sends to the [/v2/payment/status](https://api-developers.ecommpay.com/api-specification/requests-for-information/post-v2-payment-status) endpoint. The response is used to request the customer email, first and last name, billing address, and the day of birth. ```language-json HTTP/1.1 200 OK Server: api.com Date: Wed, 29 July 2019 09:27:45 GMT Content-Type: application/json; charset=UTF-8 Content-Length: 875 Connection: keep-alive Keep-Alive: timeout=60 Cache-Control: no-cache Access-Control-Allow-Methods: GET, POST, OPTIONS Access-Control-Allow-Origin: * X-Powered-By: PHP/7.0.32 Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent, X-Requested-With,If-Modified-Since,Cache-Control,Content-Type { "sum_request": { "amount": 500, "currency": "CNY" }, "request_id": "563c42d4846d105e77", "payment": { "method": "cup-card", "date": "2019-07-29T09:27:45+0000", "result_code": "9999", "result_message": "Awaiting processing", "status": "awaiting clarification", // The payment status "is_new_attempts_available": false, "attempts_timeout": 0, "id": "E2E_01_0868", "cascading_with_redirect": false, "provider_id": 1145 }, "sum_real": { "amount": 500, "currency": "CNY" }, "customer": { "id": "7826" }, "clarification_fields": { // The additional information requested "customer": [ "email", "first_name", "last_name", "billing.address", "billing.city", "billing.country", "billing.postal", "day_of_birth" ] }, "general": { "project_id": 245, "payment_id": "E2E_01_0868", "signature": "MYiga7aoW0UBFBfeTdIiF0QFOokEfyuSA==" }, "description": "", "operations": [ { "id": 1315207090506, "type": "sale", "status": "awaiting clarification", "date": "2019-07-29T09:27:45+0000", "processing_time": null, "request_id": "563c42d4846d105e77", "sum": { "amount": 500, "currency": "CNY" }, "code": "9999", "message": "Awaiting processing" } ] } ``` ## Request format {#section_vgx_ww5_zgb .section} Your web service needs to submit the requested additional payment information in a request to the [/v2/payment/clarification](https://api-developers.ecommpay.com/api-specification/additional-information-submission/post-v2-payment-clarification) endpoint by using POST HTTP method. The request must contain the following: - `general`—object that contains general request identification information: - `project_id`—the project ID obtained from Ecommpay - `payment_id`—payment ID unique within the project - `signature`—signature created after you specify all the required parameters. For more information about signature generation, see [Signature generation and verification](en_platform_signature.md#). - `additional_data` — object that contains additional payment information that payment platform requests. The object may list all the parameters, part of the parameters, or no parameters at all. **Note:** The `interface_type` object is optional. Thus, a correct request must include project and payment IDs, signature and additional payment information.In the following example, the requested additional information includes the customer postal code and address that the payment platform requests in the callback example above. ```language-json { "general": { "project_id": 11, "payment_id": "EPr-bf14", "signature": "v7KNMpfogAthg1ZZ5D/aZAeb0VMdeR+CqghwSm...==" }, "additional_data": { "avs_data":{ "avs_post_code": "99546", "avs_street_address": "01 Main Street, CA" } } } ``` The following is the example that contains two request bodies. In this way, a merchant web service prolongs payment processing, when it needs more than 30 minutes to collect all the additional data. In the example, a merchant web service sends the first request with empty additional data just to prolong payment processing. Then, a merchant web service resends the request with all the requested additional data that includes the customer email address, first and last name, billing address and date of birth that the payment platform requests in the response example above. ```language-json // The request body that the merchant web service sends // to prolong the payment processing. { "general": { "project_id": 245, "payment_id": "E2E_01_0868", "signature": "5uco0y4eeTdf59R/1SQXdfepidfw==" }, "additional_data": { } } // The request body that the merchant web service sends // to submit the additional information the payment system requests. { "general": { "project_id": 245, "payment_id": "E2E_01_0868", "signature": "5u5468co0fgfgfg/1fgfSfggdffg==" }, "additional_data": { "customer": { "email": "test@testmail.com", "first_name": "杨", "last_name": "思荣", "billing": { "address": "和飞机的事", "city": "市区-东城区", "country": "CN", "postal": "156114" }, "day_of_birth": "12-12-1990" } } } ``` **Parent topic:**[Auxiliary procedures](en_gate_procedures.md) --- # Currency conversion {#en_Gate_Conversion .concept} An article about processing payments via Gate in different currencies with currency conversion. ## Overview {#section_g2z_3kl_bbb .section} In general, a payment may involve three currencies: customer account currency, payment currency, and merchant account currency. If all three currencies are the same, there is no need for currency conversion; otherwise you need to convert the payment amount between currencies. Suppose that the customer uses their dollar-denominated card to pay a certain amount in euros to the merchant whose account is denominated in pound. The payment amount is consecutively converted from dollars to euros and then from euros to pounds. The first conversion operation is performed by the issueror by the alternative payment system. The second conversion operation is performed by the Ecommpay payment platform. You can also perform the conversion on your side and send the converted amount in the desired currency in the requests for operations performing. For payments that use Gate, the Ecommpay payment platform offers *Automatic payment currency selection*: the customer cannot select payment currency while the exchange rate is dictated by the payment system.This option is available for payouts and one-time purchases by using all payment methods. Automatic payment currency selection uses exchange rates set by Ecommpay. To learn more about exchange rates, contact your account manager. You can get the information about conversion operations performed by the payment platform from the callbacks with payment results, from Dashboard, or from regular reports sent to email addresses you specify. We recommend that you use this information for reconciliation with Ecommpay because issuersand alternative payment systems use the merchant account currency to keep record of the merchant transactions. It should be also taken into account that the operation amount and the amount actually debited from the customer's account may not be the same, since currency exchange rates usually differ on the date when the payment was initiated and the date when the funds were actually debited. For conversion and compensation in such cases, the customer should contact the card issueror the organization where the account is opened. To find out which payment methods in which currencies support conversion, please refer to the description of this method or to the Ecommpay key account manager. ## Setup {#section_u2c_qrk_kjb .section} You do not need to update your web service to support automatic payment currency selection. ## Usage {#section_zh4_qrk_kjb .section} Automatic payment currency selection does not require any additional efforts and is automatically performed during payment procedure. Any conversion information is added in payment result callbacks into two objects embedded into the `operation` object: the `sum_initial` object contains the amount and the currency before conversion while the `sum_converted` object contains the amount and the currency after the conversion operation. For more information about these objects, see [Handling callbacks](en_platform_callbacks.md#). Below you will find the example of payment with a conversion operation in which `100 USD` are converted into `519,41 PHP` debited to merchant account denominated in Philippine peso. ```language-json { "project_id": 239, "payment": { "id": "EPfa87-bcfd", "type": "purchase", "status": "success", "date": "2020-03-06T14:11:00+0000", "method": "Philippines banks", "sum":{ "amount":10000, // Initially requested amount "currency":"USD" // Initial requested currency }, "description": "" }, "operation": { "id": 464, "type": "sale", "status": "success", "date": "2020-03-06T14:11:00+0000", "created_date": "2020-03-06T14:10:34+0000", "request_id": "f6ab99eb0940e43a774b969cb74a88ef08eec6c8951-00000001", "sum_initial": { "amount":10000, // Initially requested amount "currency":"USD" // Initially requested currency }, "sum_converted": { "amount":519410, // Amount after conversion "currency":"PHP" // Automatically selected target currency }, "code": "0", "message": "Success", "provider": { "id": 1369, "payment_id": "7QKID3P3", "auth_code": "", "endpoint_id": "BOG", "date": "2020-03-06T14:10:54+0000" } }, "signature": "YZKXHr2ZdK3tPqiMzPpSJZ...+WGku5dANQAVWPteHKmwzMQ+mvGoA==" } } ``` **Parent topic:**[Auxiliary procedures](en_gate_procedures.md) --- # Additional capabilities {#en_Gate_Additional_capabilities .concept} Articles about additional capabilities of Gate for boosting payment acceptance rates, customer convenience, and the quality of the provided services. This section provides the information about various capabilities that can be implemented upon the merchant request for improving the provided service. ## Monitoring payment processing {#section_cvs_fgd_stb .section} The information about the capability of getting up-to-date information about particular payments processedvia the Gate API—[Checking current payment information](en_Gate_payment_status_request.md#). ## Boosting payment acceptance rates {#section_frq_sfd_stb .section} The information about the capabilities that can be used for ensuring high acceptance rates: - [Cascade payment processing](en_gate_cascading.md#)—about the capability of making additional purchase processing attempts \(when relevant\). - [Processing purchases with partial authorisation](en_gate_partial_approval.md)—about the capability of processing purchases with the payment amount partially approved by the issuer. - [Checking payment method availability](en_gate_available_methods.md)—about the capability of getting payment method availability information for processing a payment. ## Using payment data {#section_zzs_ghd_stb .section} The information about the capabilities of saving and using customer payment data, with the use of arbitrarily assigned identifiers \([Saving payment data](en_gate_saved_data.md)\) and standardised tokens \([Using tokens](en_Gate_Token.md)\), network tokens \([Using Mastercard and Visa network tokens](en_gate_tokens.md)\), and the information about the capability of migrating payment data to the platform \([Migrating information about COF purchases and payment card tokens](en_gate_data_migration.md#)\). ## Supporting specific scenarios {#section_qbd_yhd_stb .section} The information about the capabilities of using the Gate API in specific casesrelevant for different industries, types of business, and other situations: - [MO/TO payment processing](en_Gate_moto.md)—about the capability of processing purchases with the use of the customer's payment data received via email, phone, or other communication channels. - [Cardholder name verification](en_gate_cardholder_name_verification.md)—about the capability of matching the spelling of the cardholder's name against the one held by the card issuer. - [Using Mastercard MoneySend and Visa Direct services](en_gate_money_transfer_services.md#)—about the capability of transferring funds between customers and merchants via the Mastercard MoneySend and Visa Direct services. - [Debt repayment](en_Gate_debt_repayments.md)—about the capability of processing payments for accepting loan and credit repayments. - [Using addendum with airline tickets data](en_gate_addendum.md#)—about the capability of using the extended set of parameters \(*financial detail addendum*\) when processing air travel payments. - [Specifying extended purchase data for subsequent merchant use](en_gate_additional_data.md#)—about the capability of passing relevant purchase information to be used by merchants at their discretion. ## Informing customers {#section_fqq_mmd_stb .section} The information about the capabilities that can be used for informing customers: - [Using dynamic merchant descriptor](en_gate_descriptor.md)—about the capability of providing customers with information about merchants via issuer services. - [Sending notifications to customers](en_gate_receipts.md#)—about the capability of informing customers about payment processing and related events via email notifications. - **[Checking current payment information](en_Gate_payment_status_request.md#)** An article about the capability of obtaining via Gate up-to-date information about specific payments regardless of the interface that was used to initiate them. - **[Cascade payment processing](en_gate_cascading.md#)** An article about the capability of making additional attempts to process a payment via Gate. - **[Checking payment method availability](en_gate_available_methods.md)** An article about the capability of obtaining via Gate payment method availability information for processing a specific payment. - **[Processing purchases with partial authorisation](en_gate_partial_approval.md)** An article about the capability of processing purchases via Gate with the payment amount partially approved by the issuer. - **[Saving payment data](en_gate_saved_data.md)** An article about the capability of saving and using customer payment data for payment processing via Gate, with the use of arbitrarily assigned identifiers. - **[Using tokens](en_Gate_Token.md)** An article about the capability of saving and using customer payment data for payment processing via Gate, with the use of standardized internal tokens. - **[Using Mastercard and Visa network tokens](en_gate_tokens.md)** An article about the capability of saving and using customer payment data for payment processing via Gate, with the use of Mastercard and Visa network tokens. - **[Migrating information about COF purchases and payment card tokens](en_gate_data_migration.md#)** An article about the capability of migrating information about recurring purchases and payment card tokens from other acquirers to the Ecommpay platform. - **[MO/TO payment processing](en_Gate_moto.md)** An article about the capability of processing via Gate purchases with the use of the customer's payment data received through email, phone, or other communication channels. - **[Cardholder name verification](en_gate_cardholder_name_verification.md)** An article about the capability of matching the spelling of the cardholder's name against the one held by the card issuer during payment processing via Gate. - **[Using Mastercard MoneySend and Visa Direct services](en_gate_money_transfer_services.md#)** An article about the capability of transferring funds between customers and merchants via the Mastercard MoneySend and Visa Direct services. - **[Debt repayment](en_Gate_debt_repayments.md)** An article about the capability of processing loan repayments via Gate. - **[Using addendum with airline tickets data](en_gate_addendum.md#)** An article about the capability of using the extended set of parameters \(financial detail addendum\) when processing air travel payments via Gate. - **[Specifying extended purchase data for subsequent merchant use](en_gate_additional_data.md#)** An article about the capability of capturing relevant purchase information via Gate for internal merchant use. - **[Using optional parameters for payments processing](en_Gate_extra_params.md)** An article about the capability of using additional parameters that are relevant to merchants and cannot be found in the the Gate API. - **[Using dynamic merchant descriptor](en_gate_descriptor.md)** An article about the capability of providing customers with information about merchants via issuer services. - **[Sending notifications to customers](en_gate_receipts.md#)** An article about the capability of informing customers about payment processing and related events via email notifications. **Parent topic:**[Gate](en_Gate_Integration_About.md) --- # Checking payment method availability {#en_gate_available_methods} An article about the capability of obtaining via Gate payment method availability information for processing a specific payment. When working with different payment methods, in some cases you may need to get updates on their availability, for example, to keep the list of methods available to your customers accurate and up to date. The Ecommpay payment platform supports the capability of checking payment method availability via an API both for individual and for all integrated methods. At the same time, however, keep in mind that even if the payment method is available, the problems when processing payments made with this method can still occur. To check payment method availability, use requests to the [/v2/info/available-methods/\{payment\_direction\}/list](https://api-developers.ecommpay.com/api.html/v2-info-available-methods-payment-direction-list) endpoints where `payment_direction` indicates the payment category you need: `payin` for purchases of any type and `payout` for payouts. When working with these requests, keep in mind the following: - Each request must contain the `general` object with two parameters: - `project_id`—project identifier obtained from Ecommpay during integration. - `signature`—request signaturegenerated after all required parameters are specified \(for details, see [Signature generation and verification](en_platform_signature.md#)\). - If you need to check payment method availability for one or several specific payment methods, pass the `payment_method_list` array that specifies the [payment method code](en_pm_codes.md) for each method individually as a value of the `payment_method` parameter. ```language-json { "general":{ "project_id": 50, "signature": "qflDO7yiPKCFTyqCAaT+2/f9Gi20aV5woHKyf6J/CGJyuSjq1GH7BYgmil8APKojXw==" }, "payment_method_list": [ { "payment_method":"etoken" }, { "payment_method":"google-pay" } ] } ``` ```language-json { "general":{ "project_id": 50, "signature": "qflDO7yiPKCFTyqCAaT+2/f9Gi20aV5woHKyf6J/CGJyuSjq1GH7BYgmil8APKojXw==" } } ``` A payment method availability request is processed according to the synchronous model of interaction between the web server and the payment platform. This implies that the request is fully processed within one HTTP session and uses only the resources of the payment platform. The response to the correct request contains an HTTP response status code \(`200`\) and the required data without detailed request processing information. If the request is incorrect, or there have been issues with its acceptance and processing, then the response contains an HTTP response status code, request processing status `error` and the detailed description of the error that occurred. To learn more about HTTP response status codes, see [Interaction concepts](en_gate_interaction_organisation.md#), and to learn more about the response codes that provide information on operation processing in the payment platform, see [Handling operation processing information](en_platform_payment_info_codes.md). The body of the response to the correct request contains the project identifier, the signature, and the payment method availability array. ```language-json { "project_id": 50, "signature": "qflDO7yiPKCFTyqCAaT+2/f9Gi20aV5woHKyf6J/CGJyuSjq1GH7BYgmil8APKojXw==", "available_methods":[ { "payment_method":"etoken", "is_available": false }, { "payment_method":"google-pay", "is_available": true }] } ``` ```language-json { "project_id": 50, "signature": "qflDO7yiPKCFTyqCAaT+2/f9Gi20aV5woHKyf6J/CGJyuSjq1GH7BYgmil8APKojXw==", "available_methods":[ { "payment_method":"card", "is_available": true }, { "payment_method":"etoken", "is_available": false }, { "payment_method":"google-pay", "is_available": true }] } ``` **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Processing purchases with partial authorisation {#en_gate_partial_approval} An article about the capability of processing purchases via Gate with the payment amount partially approved by the issuer. ## Overview {#section_slr_23r_c3c .section} During payment processing, you can encounter situations when the customer's account has insufficient balance for paying the full amount, but you would rather accept a portion of the payment amount than decline the whole payment. For example, it can be relevant when the customer adds funds to their account in the web service: it might not cover the full amount of the subscription fee, but at least a part of it will be paid. To accept such payments and avoid declining them due to insufficient funds, you can use the functionality of partial authorisation \(also referred to as partial approval\) when a portion of the payment amount is approved by the issuer. This feature is supported by specific card networks. The Ecommpay payment platform supports processing purchases with partial authorisation for standard card payments made with Mastercard and Visa. This capability is enabled upon agreement with your Ecommpay account manager for specific projects, following which you can request to apply partial authorisation to each payment initiated on the side of the web service. You can use a specialised parameter `allow_partial_approval` that was added to the request structure in the API specification. The exact amount for which the purchase can be authorised is determined each time by the issuer of the card used for making this purchase\(the amount depends on the available balance on the customer's card\). The information about this amount is passed from the issuer to the Ecommpaypayment platform where the approved amount is counted as the actual payment amount, while the initially requested payment amount is ignored. Note that this change can affect subsequent operations within this purchase, for example, capturing the funds held as part of a two-step purchase, or refunding the purchase amount.For example, if the purchase for the *initially requested* amount of `100 EUR` was *partially approved* for the amount of `90 EUR` \(the sum actually paid by the customer\), partial refund can be requested only for the amount lower than `90 EUR`. In turn, the difference between the initial and approved amounts can be paid \(and if needed, refunded\) separately, with the use of a separate payment request. The use of partial authorisation capability does not affect standard payment processing workflows as to the interaction between the web service and the payment platform. However, when using this capability, you should be aware of changes in the request and callback formats \(more on this below\) and be ready to supplement user scenarios as follows. You need to: - Inform your customers that partial authorisation capability is available or make sure they can consent to this payment option—before every purchase to which partial authorisation feature applies. - Inform you customers about the partially approved and paid amount—after every purchase with partial authorisation has been completed. - Provide your customers with the possibility to pay the outstanding amount by making a separate payment\(with the use of a different payment instrument\)—if necessary. - Ensure the possibility to refund the paid amount—if necessary. - Add other changes and modifications—if it is dictated by the specifics of the web service or the services you provide. If you have questions about the integration of the partial authorisation capability, refer to your Ecommpay account manager. If you have technical questions about the use of this capability, refer to the Ecommpay support specialists ## Special aspects and limitations {#section_j1f_mbz_c3c .section} When working with the capability of processing purchases with partial authorisation, consider the following special aspects and limitations: - This capability is supported for purchases made with Mastercard and Visa cards, in cases when the issuer of the specific card supports partial approvals. If the issuer does not support this capability and the customer's account has insufficient balance, the purchase is declined. - This capability must be enabled for the project. If this capability is not enabled and the customer's account has insufficient balance, the purchase is declined even if the request contains an indicator that partial approval is allowed. - Partial authorisation can be applied to one-step and two-step purchases as well as one-click purchases if their terms are stored on the side of the web service\(the value of `stored_card_type` parameter is `2`, [details](en_Gate__payments_on_saved_data.md)\). If a COF purchase is registered, the initial payment can be partially authorised. However, even if the initially requested payment amount has been changed, the actual amount of the series of debitings that is being registeredwill not be affected. If the request to initiate an on-demand or a regular COF purchase \(the value of `stored_card_type` parameter is `4` or `6` respectively\) contains an indicator that partial approval is allowed, it will be ignored and, if the customer's account has insufficient balance, the purchase will be declined. - After the feature of partial authorisation was applied, the actual payment amount is the amount approved by the issuer. This factors in when currency conversion is used and it affects the subsequent operations within the payment including refunds and various actions performed as part of the two-step purchase \(increasing or decreasing the previously authorised amount, capturing the held funds or cancelling the hold, even if these operations are initiated automatically\). ## Setup, testing, and use {#section_pxp_2fz_c3c .section} To *enable* the partial authorisation capability: 1. With your Ecommpay account manager, discuss and agree upon setting up this capabilityand whether testing is necessary. 2. If you need testing, get notified by the Ecommpay specialists that the capability is ready for being used in test mode,test this capability, and inform Ecommpay that everything is ready to launch. 3. Get notified by the Ecommpay specialists that the capability has been added and fullyset up. To *test* accepting purchases with partial authorisation, process at least one purchase in your test projectusing the request format described [below](en_gate_partial_approval.md#section_eps_yfz_c3c) and specifying test data. - If you test processing a purchase for the amount greater than `120 EUR`\(`12000` in the smallest currency unit\) with the use of test card numbers `5126160000356675` or `4010571676223548`, the charged amount will be `120 EUR`. All other parameters, including the name of the cardholder or the verification code, can contain arbitrary values but should be specified in appropriate format\(for example, the card expiry date must occur after the payment date\). - In other cases, the full purchase amount will be charged or the purchase will be declined\(according to the processing scenarios set up for the project\). ``` {#codeblock_jn2_yqx_f3c .language-json} { "general": { "project_id": 41, "payment_id": "test_165", "signature": "MpdRv7dsOtVftZ1ZZ5D/aZAebeR+CqGrNw...==" }, "payment": { "amount": 15000, "currency": "EUR", "allow_partial_approval": true }, "card": { "pan": "4010571676223548", "year": 2035, "month": 8, "card_holder": "JANE DOE", "cvv": "123" } "customer": { "ip_address": "192.0.2.1, "id": "test_customer", "screen_res": "360x640", "phone": "999123456789", "email": "test@example.com" } } ``` ``` {#codeblock_gns_yqx_f3c .language-json} { "account": { "number": "401057******3548", "type": "visa", "card_holder": "JANE DOE", "id": 12, "expiry_month": "08", "expiry_year": "2035" }, "customer": { "id": "test_customer", "phone": "999123456789" }, "payment": { "date": "2026-01-10T13:02:42+0000", "id": "test_165", "method": "card", "status": "success", "sum": { "amount": 12000, // approved amount "currency": "EUR" }, "type": "purchase", "description": "" }, "project_id": 42, "operation": { "id": 325, "type": "sale", "status": "success", "date": "2026-01-10T13:02:42+0000", "created_date": "2026-01-10T13:01:45+0000", "request_id": "eedb14c629b4ef20b086d...d04132b0088cbc0be", "sum_initial": { "amount": 12000, "currency": "EUR" }, "sum_converted": { "amount": 12000, "currency": "EUR" }, "code": "0", "message": "Success", "eci": "07" }, "signature": "MpfogAxwRIL9tVftD/aZAeb0VMdeR+CqGUwSm...==" } ``` To *indicate* that partial authorisation can be applied to a specific payment, make surethe capability has been enabled and include the `allow_partial_approval` parameter with `true` specified as its value in the payment requestsent from the web service to the payment platform. ## Request format {#section_eps_yfz_c3c .section} When sending requests to initiate purchases with partial authorisation, consider the following: 1. To initiate a purchase, send a POST request to one of the following endpoints: - for one-time one-step purchases with actual card details specified and for one-click purchases—[/v2/payment/card/sale](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale) - for one-time one-step purchases with the saved card identifier specified—[/v2/payment/card/sale/saved](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale-saved) - for one-time one-step purchases with the card token specified—[/v2/payment/card/sale/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale-token) - for one-time two-step purchases with actual card details specified—[/v2/payment/card/auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth) - for one-time two-step purchases with the saved card identifier specified—[/v2/payment/card/auth/saved](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth-saved) 2. Each request must contain objects and parameters required for processing a purchase of a specific type\(more information can be found in the descriptions of request formats for initiating [one-step](en_gate_payment_sale.md#) and [two-step](en_gate_payment_auth.md#) purchases and [one-click purchases with their terms stored on the side of the web service](en_Gate__cof_merchant_side.md#section_jbj_flf_dlb). 3. Each request must contain the `allow_partial_approval` parameter with `true` specified as its value in the `payment` object.If `false` is passed, or this parameter is not passed in the request at all, partial authorisation is not allowed. 4. Additionally, any other parameters included in the API specification of the endpoint can be used. ``` {#codeblock_izf_fkt_yhc .language-json} { "general": { "project_id": 42, "payment_id": "135113521359", "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" }, "payment": { "amount": 10000, "currency": "EUR", "allow_partial_approval": true }, "card": { "pan": "4314220000000056", "year": 2035, "month": 8, "card_holder": "Prostetnik Jeltz", "cvv": "521" } "customer": { "ip_address": "93.47.230.225", "id": "customer_12", "screen_res": "360x640", "phone": "44991234567", "email": "p.jeltz@mail.com" }, "return_url": { "success": "https://cosmoshop.jupiter.example/pages/success", "decline": "https://cosmoshop.jupiter.example/pages/decline" } } ``` ``` {#codeblock_t1n_rsg_23c .language-json} { "general": { "project_id": 42, "payment_id": "135113521359", "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" }, "payment": { "amount": 10000, "currency": "EUR", "allow_partial_approval": true }, "card": { "pan": "4314220000000056", "year": 2035, "month": 8, "card_holder": "Prostetnik Jeltz", "cvv": "521" } "customer": { "ip_address": "93.47.230.225", "id": "customer_12", "screen_res": "360x640", "phone": "44991234567", "email": "p.jeltz@mail.com" }, "return_url": { "success": "https://cosmoshop.jupiter.example/pages/success", "decline": "https://cosmoshop.jupiter.example/pages/decline" } } ``` ## Callback format {#section_pzd_1gz_c3c .section} Results of purchases with partial authorisation are communicated in callbacks with standard format.To learn more about the callback format, see [Handling callbacks](en_platform_callbacks.md#). Note that parameters `sum`, `sum_initial`, and `sum_converted` passed in the `payment` and `operation` objects contain the amount approved by the issuer, and this amount should be used for reporting and reconciliation. The following example contains the result of processing a one-time purchase for the amount of `90 EUR` approved by the card issuer. \(The example of the initial payment request specified the amount of `100 EUR`.\) ``` {#codeblock_avz_wkt_yhc .language-json} { "account": { "number": "431422******0056", "type": "visa", "card_holder": "PROSTETNIK JELTZ", "id": 45678, "expiry_month": "08", "expiry_year": "2035" }, "customer": { "id": "customer_12", "phone": "44991234567" }, "payment": { "date": "2026-01-11T13:02:42+0000", "id": "456789", "method": "card", "status": "success", "sum": { "amount": 9000, // approved amount in the requested payment currency "currency": "EUR" // code of the requested payment currency }, "type": "purchase", "description": "" }, "project_id": 42, "operation": { "id": 969000002636, "type": "sale", "status": "success", "date": "2026-01-11T13:02:42+0000", "created_date": "2026-01-11T13:01:45+0000", "request_id": "c6eed1eb14c629b4ef20b3b8086d...d04132c34b0088cbc0be4667c", "sum_initial": { "amount": 9000, // approved amount in the requested payment currency "currency": "EUR" // code of the requested payment currency }, "sum_converted": { "amount": 7805, // approved amount in the actual operational currency "currency": "GBP" // code of the actual operational currency }, "provider": { "id": 408, "payment_id": "330157196", "date": "2026-01-11T13:02:32+0000", "auth_code": "", "endpoint_id": "612266625" }, "code": "0", "message": "Success", "eci": "07" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" } ``` ``` {#codeblock_stx_5sg_23c .language-json} { "account": { "number": "431422******0056", "type": "visa", "card_holder": "PROSTETNIK JELTZ", "id": 45678, "expiry_month": "08", "expiry_year": "2035" }, "customer": { "id": "customer_12", "phone": "44991234567" }, "payment": { "date": "2026-01-11T13:02:42+0000", "id": "456789", "method": "card", "status": "success", "sum": { "amount": 9000, // approved amount in the requested payment currency "currency": "EUR" // code of the requested payment currency }, "type": "purchase", "description": "" }, "project_id": 42, "operation": { "id": 969000002636, "type": "sale", "status": "success", "date": "2026-01-11T13:02:42+0000", "created_date": "2026-01-11T13:01:45+0000", "request_id": "c6eed1eb14c629b4ef20b3b8086d...d04132c34b0088cbc0be4667c", "sum_initial": { "amount": 9000, // approved amount in the requested payment currency "currency": "EUR" // code of the requested payment currency }, "sum_converted": { "amount": 7805, // approved amount in the actual operational currency "currency": "GBP" // code of the actual operational currency }, "provider": { "id": 408, "payment_id": "330157196", "date": "2026-01-11T13:02:32+0000", "auth_code": "", "endpoint_id": "612266625" }, "code": "0", "message": "Success", "eci": "07" }, "signature": "v7KNMpfogAxwRIL9tVftZ1ZZ5D/aZAeb0VMdeR+CqGrNxYyilUwSm...==" } ``` ## Useful links {#section_kxp_mlz_c3c .section} The following materials can be useful when you work with the capability of partial authorisation: - [One-time purchases](en_Gate_purchase.md)—a section with articles about processing one-time one-step and two-step purchases via Gate, including description of processing workflows and data formats for working with standard card payments. - [Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md)—a section with articles about registering and processing COF purchases via Gate, including description of processing workflows and data formats for working with standard card payments. - [Purchase refunds](en_Gate_Refund.md)—an article about refunding purchases via Gate, including general information about refunds and description of data formats for working with standard card payments. - [Handling payment processing information](en_platform_payment_information.md)—a section with articles about different ways to receive data that merchants can use to monitor and analyse payment processing activity. **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Saving payment data {#en_gate_saved_data .concept} An article about the capability of saving and using customer payment data for payment processing via Gate, with the use of arbitrarily assigned identifiers. For convenience of quick and efficient payment customers can save the data of one or several bank cards, e-wallets, accounts, mobile numbers or any other payment instrument when performing a payment. If you obtain the [PCI DSS](https://www.pcisecuritystandards.org/pci_security/) certificate, you can store the card data on your side, if not—on Gate side. For each payment instrument, Gate saves the payment credentials and assigns the instrument its own ID. Gate supports the maximum quantity limits of the payment instruments a customer can save. **Note:** To enable and configure the service contact the technical support by email [support@ecommpay.com](mailto:support@ecommpay.com). **Warning:** To save and perform payments on saved data, pass the id parameter of the customer object in the request for payment. ## Retrieving the list of saved payment data {#section_yz5_kyy_wbb .section} Additionally, you can request a list of the customer's saved instruments and their details; in this case the number of the customer card is masked and CVV is not sent. ## Request to retrieve the list of saved payment data {#section_h5b_zdn_jbb .section} **Note:** POST the [/v2/customer/saved\_account/list](https://api-developers.ecommpay.com/api-specification/requests-for-customer-details/post-v2-customer-saved-account-list) request. In the request specify the customer id, the project id, and the payment system. When Gate finishes processing the request, you receive a response with the list of customer's saved payment instruments. The response will not contain the list if no payment instruments were savedin the selected payment system. For each payment instrument, its ID in Gate is specified in the account\_id orcard\_id parameter. ## Deleting saved payment data {#section_qy2_zyy_wbb .section} When a customer deletes previously saved payment instrument, send the request for removal. In this case, Gate removes the instrument from the list of saved payment instruments, but does not delete its data. **Note:** If the saved card has a token, the token will be deleted when the saving of the card is canceled. Alternatively, a saved bank card is removed when you revoke the token of this card. For more information about tokens, see [Using tokens](en_Gate_Token.md). ## Request to delete a payment data from the saved list {#section_nh4_zdn_jbb .section} **Note:** POST the [/v2/customer/saved\_account/delete](https://api-developers.ecommpay.com/api-specification/requests-for-customer-details/post-v2-customer-saved-account-delete) request. In the request specify the ID of the saved payment instrument. When Gate finishes processing of your request you receive a reply with the result of removal of the payment instrument from the saved list. **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Using tokens {#en_Gate_Token .concept} An article about the capability of saving and using customer payment data for payment processing via Gate, with the use of standardized internal tokens. **Token** is a unique, random sequence of 64 characters associated in Gate with a specific bank card and the customer in the project. Token does not contain a confidential information and can be stored in your system without threatening to violate the standards of secure bank card data storage. By using Gate you can create tokens automatically or by request and make puchases and payouts by using existing tokens. ## Statuses of tokens {#section_txw_jp2_zbb .section} The status of a token defines if the token can be used to perform payments and payouts. |Status|Description| |------|-----------| |active|Token is active and can be used to perform payments and payouts| |revoke|Token is revoked and cannot be used to perform payment and payouts| |expiry|Token has expired and cannot be used to perform payment and payouts| ## Automatic token generation {#section_jrt_kzd_lbb .section} *Automatic generation* procedure creates a token when the first successful purchase or payout is performed by using a bank card, as well as after holding the funds on a bank card. The generated token and the date when it was created are returned in the payment callback. For more information about callbacks, see in [Handling callbacks](en_platform_callbacks.md#). **Note:** To enable automatic token generation, contact technical support by email [support@ecommpay.com](mailto:support@ecommpay.com). ## Token generation by request {#section_emy_sg2_lbb .section} Another way to generate a token is to send a request to generate a token. In the request you send the data required to generate the token. The generated token and the time it was created at are returned in the token generation response. ## Token generation request {#section_vft_rzd_lbb .section} **Note:** POST the [/v2/customer/card/tokenize](https://api-developers.ecommpay.com/api-specification/token-operations/post-v2-customer-card-tokenize) request. Specify the project id, customer data and data of customer bank card in the request. You receive in the callback a bank card token and the time when it was generated. For more information about callbacks, see in [Handling callbacks](en_platform_callbacks.md#). ```language-javascript { "customer": { "id": "1707", "ip_address": "1.87.128.111", "project_id": 11, "signature": "LLmhbDKdNhNLT+Qkr2SzbLbFYNxC9sZLnQKkrTFYNN06NMPmZS/BfWGucWQVZ2WM3v5N709w==" }, "card": { "pan": "4314220000000056", "year": 2020, "month": 5, "card_holder": "PAUL SMITH" } } ``` ## Payment by token {#section_fcr_vxx_5bb .section} Gate enables customers to process fast payments by using a previously generated bank card token. **Note:** The token is unique to the bank card. When processing payments by bank card a valid token that already exists will be returned. The token is unique to the bank card. When processing payments by bank card a valid token that already exists will be returned. In this case, if the card expiration date is different from the one specified when the token was generated, the token is not generated anew, but the expiration date of the token is updated. Additional information about the token-based payments see in [One-time purchases](en_Gate_purchase.md). ## Payout by token {#section_zyv_mc2_lbb .section} Gate enables you to process the payout of funds to a customer's bank card by using a previously generated token. Additional information about the token-based payouts see [Payouts](en_Gate_payout.md). ## Receiving card data by token {#section_vqp_phc_yfb .section} If you need to receive bank card data and information about the payment instrument to which this card is linked, send a request to Gate. **Note:** POST the [/v2/customer/card/bytoken](https://api-developers.ecommpay.com/api-specification/token-operations/post-v2-customer-card-bytoken) request. In the request, specify the project ID, customer ID and token. You receive in the callback the masked bank card data and other information on the customer payment instrument. ``` { "customer": { "project_id": 12, "id":"test_customer", "signature":"2tlMuYxLW9Yu6RETr8pdCfmi0UPE8JguQjXWH6naCA9Ts6o4EVPjLyfbOQ+9ajAteg5lPk96Q==" }, "token":"959c664ad64b8caa54bb7836ddc737fd1a3e6c7045679d71d89caff6c242a039" } ``` ``` { "account": { "id": 2932, "number": "431422******0056", "type": "card", "additional": { "country": "GB", "phone": "4314220000000056", "email": "john@gmail.com", "card": { "expiry": "01/20", "holder": "JOHN JOHNSON", "type": "visa" } }, "recurring_enable": false }, "token": "959c664ad64b8caa54bb7836ddc777fd1a3e6c704b59bd71d89caff6c242a039" }, "signature": "62kPxuCGqN4KDrxqqsuWnv0LOjdvUydWCxDmN+AVW7/5UtLlmVL+SIyfbxot/Nf+47DEsAuW76DIgBg==" } ``` ## Card verification by token {#section_gch_npt_wmb .section} Gate enables you to perform the customer's bank card verification by using a previously generated token. The information about the token-based verification is provided in the [Payment instrument verification](en_gate_account_verification.md) section. ## Revoke of a token {#section_kw4_31z_wbb .section} A token can be revoked in one of the following happens: you revoke the token or the payment card expires. In the former case, if required, you can revoke a token from Gate by sending a request to revoke the token. Gate revokes the token. ## Request to revoke a token {#section_t5g_4ym_jbb .section} **Note:** POST the [/v2/customer/card/token/revoke](https://api-developers.ecommpay.com/api-specification/token-operations/post-v2-customer-card-token-revoke) request. Specify the customer data in your system and the token to be revoked. You receive in the callback the result of revoking of the token. ## Callback after generating or revoking a token {#section_ozl_ws3_1cb .section} Once you pass a token generation or token revoke request to the [/v2/customer/card/tokenize](https://api-developers.ecommpay.com/api-specification/token-operations/post-v2-customer-card-tokenize) endpoint, the payment platform returns a callback with the request execution result. The following table shows the parameters included in the callback. For more information about callbacks, see [Handling callbacks](en_platform_callbacks.md#). |Parameter|Description|tree| |---------|-----------|----| |general object, required |The object with the general request data.|1| |project\_id string, required |The unique identifier of your project. Example: `42`. |1-11| |customer\_id string, optional |The unique identifier of the customer in your project.|1-21| |signature string, required |Callback signature|1-31| |request object, required |The object with the request data|2| |id integer, required |Unique identifier of the request Example: `3718000054` |2-12| |action string, optional |Type of the request. The following options are available:- `tokenize`—token creation request - `token_revoke`—token revoke request - **parameter is missing from callback** — token is expired and deactivated. The platform initiates a callback with missing action automatically, immediately after the token expires. Such callback is not issued in response to a request. |2-22| |status string, required |The request status. The following options are available:- `success`—request successfully completed - `error`—error\(s\) encountered when processing request. The error details are passed in the errors array. |2-32| |errors array, optional |Array of error messages.|2-42| |ErrorItem object, required |The object with information about a single error.|2-4-12-4| |code string, optional |Error code. Example: `10309`. |2-4-1-12-4-1| |message string, optional |A message that clarifies the error cause. Example: `Attempt to make COF purchase without registered recurrent payments.` |2-4-1-22-4-1| |field string, optional |The parameter in which the error occurred if it was defined|2-4-1-32-4-1| |token string, optional |Token of the customer bank card. The token is generated automatically when a successful payment is performed if the appropriate option is enabled.|3| |token\_created\_at string, optional |The date and time the token was generated. Example: `2017-07-21T03:31:24+0000` |4| |token\_status string, optional |Token status. Example: `active` |5| ```language-xml "general":{ "project_id":12, "signature":"\/gmTHcy5wvrFD4ISuWEiV8+nOa3aqnLnyJ\/AupOYkl9S5eLJZ", "request": { "id": "3c7f53fdbb5b8c96f9707457d75f", "action": "tokenize", "status": "success" }, "token":"2f0e75befacca30623354f9ffb0f44a80bee52982c39727b85039ef6f64309a1", "token_created_at":"2017-11-28 13:30:57", "token_status":"active" } ``` **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Using Mastercard and Visa network tokens {#en_gate_tokens} An article about the capability of saving and using customer payment data for payment processing via Gate, with the use of Mastercard and Visa network tokens. ## Overview {#section_rsl_pxl_rhc .section} To improve convenience and security of card payments, global card networks offer network tokenisation solutions. A network token is created for a card of the respective card network and via a specialised service of this card network. Once created and collected, this token can be used in payment processing via any acquirer or provider that supports working with network tokens of the said card network. The Ecommpay payment platform allows you to process payments with the use of network tokens created by the Mastercard Secure Card on File \(SCOF\) service and Visa Token Service \(VTS\). A network token is a sequence of 16 characters that can be used in requests instead of the card number.When the card associated with a specific token is reissued or replaced or its details are changed in any other way, the token remains valid because the data associated with the token is updated automatically in the originating tokenisation service. When processing payments via the Ecommpay payment platform, you can use network tokens if such tokens have already been created in the third-party services and are being used on the side of the merchant web service. In other cases, you can use the capabilities of processing payments with tokens via Payment Page \([details](en_pp_token.md)\) and Gate \([details](en_Gate_Token.md)\) and migrating information about payment card tokens from other acquirers \([details](en_gate_data_migration.md#)\). If you have questions regarding the terms and conditions of using network tokens and the steps of integrating this functionality, refer to your Ecommpay account manager.If you have questions regarding the technical aspects of using network tokens, refer to the information on the documentation portal and to the Ecommpay technical support. ## Special aspects and limitations {#section_vfs_pxl_rhc .section} When processing payments with the use of network tokens, you need to consider the following: - The capability of using network tokens \(for all supported card networks\)must be enabled for the specific project. When this capability is not enabled for the project, payments with network tokens are declined with the 318 error code. - The use of network tokens is limited to several payment workflows that include processing one-time one-step and two-step purchases, registering and processing COF purchases with saved data stored on the side of the web service \([details](en_gate_payment_recurring_registration.md)\), and payment card verification. In other cases, for example, processing payment link purchases, COF payments with saved data stored on the side of the platform, or issuing payouts, you can only use tokens created in the payment platform \([details](en_Gate_Token.md)\). - Managing network tokens \(creating, updating, and receiving data required for their use\) is carried out via specialised services. To learn more about working with them, refer to documentation and specialists of these services. - The merchant is responsible for appropriate use of network tokens and the network token information. If you have questions concerning the incorrect use of network tokens, contact your Ecommpay account manager. ## Request format {#section_vtw_pxl_rhc .section} When creating a request for processing a payment with the network token, consider the following: 1. The request must be sent to one of the following endpoints with the use of the HTTP POST method: - for one-time one-step and COF purchases—[/v2/payment/card/sale](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale) - for one-time two-step purchases—[/v2/payment/card/auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth) - for payment card verification—[/v2/payment/card/account\_verification](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification) 2. In the `card` object, specify the following network token information instead of card details: - `pan`—the token created in the specialised service of the card network - `year`—the year of the token's expiration date\(in the `YYYY` format according to the Gregorian calendar\) - `month`—the month of the token's expiration date\(as a number without a leading zero\) - `card_holder`—the name of the cardholder, passed if this parameter is required for the project\(the name must be spelled as specified on the card; note that if you want to make this parameter optional instead of required, it can only be done upon consultation with your account manager which includes examination and assessment of associated risks\) - `cvv`—card verification code \(required in all cases except for processing on-demand and regular COF purchases\) 3. In the `token_data` object, pass the following parameters: - `token_type`—the type of the token with the value `network_token` \(required for each payment\) - `cryptogram`—the verification code of the network tokensuch as the Token Authentication Verification Value \(TAVV\) received from the network tokenisation service \(required for registering COF purchases and optional for other payment types\) - `eci`—[the Electronic Commerce Indicator](en_ECI_codes.md) that corresponds to the token, received from the network tokenisation service \(required for registering COF purchases and optional for other payment types - `trid`—the identifier of the merchant assigned when the merchant registers in the network tokenisation service \(optional\) 4. In the required `stored_card_type` parameter, pass one of the following values: - `1` to save payment data or register a one-click purchase - `2` to process a payment with saved payment data or a one-click purchase - `3` to register an on-demand COF purchase - `4` to process an on-demand COF purchase - `5` to register a regular COF purchase - `6` to process a regular COF purchase You can find more information about working with COF purchases in [Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md) 5. When processing a COF purchase \(the `stored_card_type` contains values `2`, `4`, or `6`\) made with a card issued in the European Economic Area, pass the `scheme_id` parameter, which is an identifier of the initial operation within which the COF purchase was registered on the side of Mastercard or Visa. 6. Additionally, you can use any other parameters from the API specification of the endpoint you need. ## Useful links {#section_mcb_qxl_rhc .section} When working with network tokens, you can also use the following articles: - [One-time purchases](en_Gate_purchase.md)—about processing of one-time one-step purchases by using Gate. - [Credential-on-file \(COF\) purchases](en_Gate__payments_on_saved_data.md)—about processing of COF purchases via Gate - [Using tokens](en_Gate_Token.md)—about processing payment with tokens generated in the payment platform. - [Migrating information about COF purchases and payment card tokens](en_gate_data_migration.md#)—about the steps for migrating information about COF purchases and tokens created by other acquirers. **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # MO/TO payment processing {#en_Gate_moto .concept} An article about the capability of processing via Gate purchases with the use of the customer's payment data received through email, phone, or other communication channels. Mail Order/Telephone Order \(MO/TO\) payment is a CNP \(card-not-present\) payment when a cardholder provides payment card credentials via mail or telephone to perform a payment. ## The types of payments that support MO/TO payment processing {#section_c22_lkx_y2b .section} The types of operations that support MO/TO functionality: - purchase with direct withdrawal of funds—[/v2/payment/card/sale](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale) - purchase with direct withdrawal of funds by using saved data—[/v2/payment/card/sale/saved](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale-saved) - purchase with direct withdrawal of funds by using token—[/v2/payment/card/sale/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale-token) - placing an authorisation hold—[/v2/payment/card/auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth) - placing an authorisation hold by using saved card data—[/v2/payment/card/auth/saved](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth-saved) - placing an authorisation hold by using the token associated with the card details—[/v2/payment/card/auth/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth-token) - payment card verification by card number—[/v2/payment/card/account\_verification](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification) - payment card verification by the token associated with the card details—[/v2/payment/card/account\_verification/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification-token) ## MO/TO payment processing by using Gate {#section_ncq_xfx_y2b .section} MO/TO payments are different from the usual ones. MO/TO payment is a type of CNP payments when both a payment card and a cardholder are not physically present at the moment the payment is made. The payment card credentials are provided by its holder by mail, telephone, fax or other means of communication to create an invoice. To perform a MO/TO payment by using Gate, pass one of the necessary values of the moto\_type parameter in the payment object: - `1` for the Mail Order \(MO\) payment - `2` for the Telephone Order \(TO\) payment ## Passing the `cvv` parameter {#section_ct3_jkx_y2b .section} If moto\_type=`1`, for Mastercard, Visa, and American Express the cvv parameter in the object card becomes optional. For other card types the parameter is mandatory. If moto\_type=`2`, for Mastercardand American Express the cvv parameter in the object card becomes optional. For other card types the parameter is mandatory. ## Restrictions on MO/TO payment processing {#section_ffr_y4h_jfb .section} To perform a MO/TO payment by using Maestro cards, you have to make sure that the country where the operation is performed matches the country where the card was issued and also be in the list of available countries. If these conditions are not met, the operation processing is declined. The countries available for MO/TO payments by using Maestro are listed in the following table. |IRL|Ireland| |FRA|France| |GBR|United Kingdom| |TUR|Turkey| **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Cardholder name verification {#en_gate_cardholder_name_verification} An article about the capability of matching the spelling of the cardholder's name against the one held by the card issuer during payment processing via Gate. ## General information {#section_zq3_2q2_zhb .section} When you perform verification of a payment card, you can also check if the spelling of the cardholder's name matches the one held by this card issuer. The Ecommpay payment platform supports this capability for Mastercard and Visa cards and carries out verification via Mastercard Name Validation Service\(NVS\) and Visa Account Name Inquiry\(ANI\)—the specialised services of these card networks. The cardholder name verificationcapability can be applicable in various situations. For example, you can use it before issuing payouts or when working with unusual orders, and it also allows you to assess fraud and chargeback risks. It is supported for standard card payments, Apple Pay and Google Pay payments, and payments via the Mastercard MoneySend and Visa Direct services. Using this capability fits within the payment instrument verification workflow \([details](en_gate_account_verification.md)\) and requires no additional action from the web service other than working with an extended set of parameters in the requests and callbacks \(more details [below](en_gate_cardholder_name_verification.md#section_rpp_v14_3fc)\). To enable this option, refer to your Ecommpay account manager. ## Special aspects and limitations {#section_td5_kdj_5yb .section} When working with the cardholder name verification, consider the following special aspects and limitations: - Verification can be performed only when the card issuer supports integration with the service provided by the card network. - Issuers may have different verification rules that allow only full name match or full and partial name match. - The degree of match for cardholder name verification should be treated as reference information only.The final decision whether to accept or reject a payment based on this information lies in each case with the merchant. - The card network charges a fee for each completed name verification attempt.No fee is charged in the case when the verification attempt has been initiated but has not been completed. For information on current name verification fees, refer to your Ecommpay account manager. - The workflow of name verification includes matching the data held by the issuer against the data specified in the request for card verificationin the `first_name`, `middle_name`, and `last_name` parameters of the `customer` object. For each of these parameters, only the first 35 characters, excluding special characters and spaces, are verified. - The match result is sent to the web service in the final callback for the payment card verificationin the `name_validation_result` parameter of the `operation` object. ## Request format {#section_rpp_v14_3fc .section} There are several things you need to consider when sending a request for the payment card verification with additional cardholder name check: 1. To initiate each verification, send a separate POST request to one of the following endpoints: - when performing verification by card number—`/v2/payment/card/account_verification` \([details](en_gate_account_verification.md)\) - when performing verification by the token that is associated with payment card details—`/v2/payment/card/account_verification/token` \([details](en_gate_account_verification.md)\) - when performing verification by using the Apple Pay method—`/v2/payment/applepay/account_verification` \([details](pm_applepay.md#)\) - when performing verification by using the Google Pay method—`/v2/payment/googlepay/account_verification` \([details](pm_googlepay.md#)\) 2. Each request must contain the following parameters in the `customer` object: - `first_name`—customer first name \(mandatory\) - `middle_name`—customer middle name or patronymic \(only if it was provided by the customer\) - `last_name`—customer last name \(mandatory\) - `name_validation`—flag indicating the need to verify the cardholder name \(required with the `true` value\) 3. Additionally, any other parameters included in the specification of the endpoints mentioned above can be used. ``` {#codeblock_dxp_wqx_jfc .language-json} { "general":{ "project_id":874, "payment_id":"15538406111", "signature":"1wR1YgD5PxxTIJfQ==" }, "customer":{ "ip_address":"192.0.2.0", "id":"customer_10", "first_name":"John", "middle_name": "Jr", "last_name": "Doe", "name_validation": true //requesting name verification }, "payment":{ "amount":0, "currency":"USD" }, //specifying the payment instrument details (as in specification) } ``` ## Callback format {#section_gq3_n12_pfb .section} The payment card verification with additional verification of the cardholder's name uses the standard format for callbacks.For more information, see [Handling callbacks](en_platform_callbacks.md#). In addition, the `operation` object in these callbacks includes the `name_validation_result` parameter. This parameter can have the following values: - `A`—the information provided in the request fully matches the information held by the issuer. - `B`—the information provided in the request partially matches the information held by the issuer. - `C`—the information provided in the request does not match the information held by the issuer. - `U`—the name matching is impossible \(because it is either not supported by the issuer or an error occurred\). The following is an example of a callback where the `name_validation_result` parameter contains the full match indicator \(`A`\). ``` {#codeblock_dd2_1tx_jfc .language-json} { "project_id":874, "payment":{ "id":"15538406111", "type":"account_verification", "status":"success", "date":"2024-09-10T13:45:59+0000", "method":"card", "sum":{ "amount":0, "currency":"USD" }, "description":"Add card" }, "account":{ "number":"431422******0056", "token":"844f84f3bdfaf2ddf006c96ffaddc09394c5d0e158f", "type":"visa", "card_holder":"JOHN DOE", "id":8861226, "expiry_month":"09", "expiry_year":"2028" }, "customer":{ "id":"customer_10", "first_name":"John", "middle_name":"Jr", "last_name":"Doe" }, "recurring":{ "id":10505, "currency":"USD", "valid_thru":"2025-09-30T00:00:00+0000" }, "operation":{ "id":4314220000000056, "type":"account verification", "status":"success", "date":"2024-09-10T13:45:59+0000", "name_validation_result": "A", //match result indicator "created_date":"2024-09-10T13:45:57+0000", "request_id":"5cb898347e62b2c1-52dac6c8c", "provider":{ "id":120, "payment_id":"306449667", "date":"2024-09-10T13:45:59+0000", "auth_code":"188591", "endpoint_id":120 }, "code":"0", "message":"Success" }, "signature":"P9g0U+eF2QWs2A==" } ``` ## Useful links {#section_d55_sxv_chd .section} The following articles can be useful for working with the cardholder name verification: - [Payment instrument verification](en_gate_account_verification.md)—about debiting a dummy \(zero\) amount or authorising a specific \(non-zero\) amount to verify a payment instrument via Gate, including information about request and callback formats in case of card payments. - [Standard card payments](en_pm_card_payments.md)—about card payments in the context of using payment methods. - [Apple Pay](pm_applepay.md#)—about working with the Apple Pay method, including information about request and callback formats in case of payment instrument verification with this method via Gate. - [Google Pay](pm_googlepay.md#)—about working with the Google Pay method, including information about request and callback formats in case of payment instrument verification with this method via Gate. - [Using Mastercard MoneySend and Visa Direct services](en_gate_money_transfer_services.md#)—about performing money transfers via specialised services by Mastercard and Visa. - [Handling callbacks](en_platform_callbacks.md#)—about working with callbacks to receive up-to-date information significant for processing of each payment. **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Debt repayment {#en_Gate_debt_repayments} An article about the capability of processing loan repayments via Gate. ## General information {#section_knc_3mq_4mb .section} *Debt repayment* is a type of purchase from the customer's card intended for payment of a loan or debt. This type of payment is available for merchants providing microfinance services with the category code `6012` or `6051`. Debt repayment can be made as a one-time purchase, registration of a COF payment, or card verification operation. If an MFI is registered in the United Kingdom \(for Mastercard payments\) or in the European region according to Visa regulations \(for Visa payments\) in addition to the required objects and parameters, the MFI account number and additional customer data must be specified in the request: - payment—object containing payment data: - debt\_account—the merchant account number for debiting funds from the customer's card in order to repay the debt. Latin letters and numbers are allowed, the maximum length is 10 characters - customer—object containing customer data: - first\_name—first name - last\_name—last name - day\_of\_birth—date of birth, in the DD-MM-YYYY format - zip—postal address code \(mandatory for the UK\). This functionality is not available for payments with American Express cards. If the parameter is not specified in the request, a callback containing this parameter is sent for additional payment information submission \(for more details, see [Submission of additional payment information](en_Gate_Clarification.md)\). ```language-json { "general": { "project_id": 200, "payment_id": "payment_id", "signature": "PJkV8ej\/UG0Di8NN5...==" }, "payment": { "amount": 1000, "currency": "EUR", "debt_account": "897896541" }, "customer": { "id": "123", "ip_address": "1.1.1.1" "first_name": "John", "last_name": "Johnson", "day_of_birth": "12-05-1990", "zip": "SW1W 0NY" } } ``` If the debt re payment is made by the registration of a COF payment—you do not need to pass additional parameters in requests for payment processing—they will be taken from the initial request for registration. For more information about this functionality and how to enable it, refer to the Ecommpay key account manager. ## Mastercard restrictions {#section_jzh_kmq_4mb .section} According to Mastercard requirements, this functionality is available to merchants from the United Kingdom only with the category code `6012`. For all other countries both `6012` or `6051` codes are available. It is prohibited to repay debts from credit and prepaid cards if the country of issue of the card and registration of the merchant is the United Kingdom. ## Visa restrictions {#section_gb2_lmq_4mb .section} According to Visa requirements, merchants from the United Kingdom who accept payment of overdue debts must have the category code `6051`. In other cases and for all other countries both `6012` or `6051` codes are available. It is prohibited to repay debts from credit cards. **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Using optional parameters for payments processing {#en_Gate_extra_params .concept} An article about the capability of using additional parameters that are relevant to merchants and cannot be found in the the Gate API. If necessary, Gate allows you to specify extra settings for processing payments performed by customers. That data should be sent in the payment.extra\_param parameter. For more information regarding this option, you may apply to your Key Account Manager. **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Using dynamic merchant descriptor {#en_gate_descriptor} An article about the capability of providing customers with information about merchants via issuer services. ## Overview {#section_u2p_3rk_mhc .section} When Ecommpay acts as an acquirer, in compliance with the rules of card networksEcommpay shares merchant details with other parties involved in payment processing. These detailscan be used by each party at its discretion and can be specified in receipts and bank statements by issuers. By default, merchant information isstatic and limited to theagreed upon name of the merchant. However, the merchant can dynamically append additional detailsrelating to a particular payment or other aspects of their business. These dynamic descriptions can be included in payment requestsand are only limited to the maximum string length and the permitted character set \([details](en_gate_descriptor.md#section_b3f_hvp_13c)\). For example, the merchant descriptor can include the merchant's name combined with a booking period \(`Cosmotour* 17-19 feb`\) or with the name of the reserved hotel \(`Cosmotour* MarsSuite`\). ![](images/ecommpay/en_gate_descriptor_2.svg "Adding booking period") ![](images/ecommpay/en_gate_descriptor_1.svg "Adding hotel name") Flexible use of accurate and informative details makes it easier for customers to identify merchants and payments and allows merchants to improve user experience and reduce the risk of disputes.In the Ecommpay payment platform, dynamic descriptors are relevant for *card payments* \(including standard card payments and payments made with Apple Pay, Click to Pay, Google Pay, and Visa Instalments\) and such payment types as one-time and COF purchases, payouts, and payment instrument verification. ## Special aspects {#section_fhg_s3m_djc .section} When working with merchant data, consider the following special aspects: - The primary purpose of the merchant descriptor is to help customers recognise payments they made and prevent unnecessary chargebacks. Hence, avoid ambiguous or potentially misleading information in the merchant descriptor. Focus on the information that enables the customer to identify both the merchant and each operation clearly. In particular, it is recommended that you use a familiar brand name together with a concise description of the goods or services related to the operation. - Requirements to the merchant descriptor can vary depending on the card network. Pay attention to such differences, at least regarding the supported formats \([details](en_gate_descriptor.md#section_b3f_hvp_13c)\). - The way merchant details are provided to customers is determined by issuers. How merchant details will appear in receipts, bank statements, and other communication with the customer is determined by the rules of a specific issuer. As a result, merchant details may vary across issuers, different interfaces of the same issuer, and different operation types within a single interface. In particular, there may be differences due to processing different types of purchases ans payouts as well as Mastercard MoneySend and Visa Direct operations. ## Setup {#section_p14_v5p_13c .section} The name of the merchant to be used as a default merchant descriptor is specified when the merchant is onboarded with the payment platform and, subsequently, can only be modified via the Ecommpay account manager. To enable the use of the dynamic merchant descriptor, continue as follows: 1. Coordinate with the Ecommpay account manager the roadmap of enabling the functionalityfor specific projects and the necessity for testing.. 2. If you need testing, get notified by the Ecommpay specialists that the capability is ready for being used in test mode,test this capability, and inform Ecommpay that everything is ready to launch. 3. Get notified by the Ecommpay specialists that the capability has been added and fullyset up. ## Use {#section_dh5_v5p_13c .section} If you need to use the dynamic merchant descriptor, include the `descriptor` parameter in the payment requests. Pass this parameter inthe `merchant` and `sender` objects. If both objects are supported for a given endpoint, the `descriptor` parameter can be specified in either. However, when both objects are passed, priority is given to a more relevant object: - `merchant` for purchases and payment instrument verification - `sender` for payouts Keep in mind that in cases when the value of the `descriptor` parameter does not conform to the required format \([details](en_gate_descriptor.md#section_b3f_hvp_13c)\), the platform can automatically correct it\(for example, by transliterating alphabetic characters and removing invalid non-alphabetic characters\). Such correction of values does not lead to declined payments. Also, note that the Ecommpay platform does not validatethe value of the `descriptor` parameterfor factual correctness, but this information can be analysed and subsequently used by the issuers. Merchants should therefore ensure that values provided in the `descriptor` parameter are both technically compliant and contextually accurate in every instance of use. - for one-time one-step purchases with payment details provided as is or via the network tokens—[/v2/payment/card/sale](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale) - for one-time one-step purchases with payment details provided via the internal tokens generated in the platform—[/v2/payment/card/sale/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-sale-token) - for one-time two-step purchases with payment details provided as is or via the network tokens—[/v2/payment/card/auth](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth) - for one-time two-step purchases with payment details provided via the internal tokens generated in the platform—[/v2/payment/card/auth/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-auth-token) - for COF purchases of all types—[/v2/payment/card/recurring](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-recurring) - for payouts with payment details provided as is—[/v2/payment/card/payout](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-payout) - for payouts with payment details provided via the internal tokens generated in the platform—[/v2/payment/card/payout/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-payout-token) - for payment instrument verification with payment details provided as is or via the network tokens—[/v2/payment/card/account\_verification](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification) - for payment instrument verification with payment details provided via the internal tokens generated in the platform—[/v2/payment/card/account\_verification/token](https://api-developers.ecommpay.com/api-specification/card-payments/post-v2-payment-card-account-verification-token) - for one-time one-step purchases—[/v2/payment/applepay/sale](https://api-developers.ecommpay.com/api-specification/apple-pay/post-v2-payment-applepay-sale) - for one-time two-step purchases—[/v2/payment/applepay/auth](https://api-developers.ecommpay.com/api-specification/apple-pay/post-v2-payment-applepay-auth) - for one-time one-step purchases—[/v2/payment/googlepay/sale](https://api-developers.ecommpay.com/api-specification/google-pay/post-v2-payment-googlepay-sale) - for one-time two-step purchases—[/v2/payment/googlepay/auth](https://api-developers.ecommpay.com/api-specification/google-pay/post-v2-payment-googlepay-auth) ## Data format {#section_b3f_hvp_13c .section} The maximum length of the merchant descriptor is determined by the card network. Mastercard sets a maximum length of 22 characters, while Visa sets a maximum length of 25 characters.Any characters exceeding these limits are truncated. Keep these limits and the allowed character requirements in mind when generating descriptions. The `descriptor` parameter can contain characters from the basic Latin alphabet, digits, a space character \(U+0020\), and the following symbols: |`*`|U+002A|asterisk| |`,`|U+002C|comma| |`-`|U+002D|hyphen| |`.`|U+002E|full stop| |`=`|U+003D|equals sign| |`_`|U+005F|underscore| When generating the `descriptor` parameter, use the agreed uponmerchant's name followed by additional details separated by an asterisk \(`*`\) and a space, ensuring compliance with the applicable string length restrictions. For example, if a 9-character name `Cosmotour` is used with a 2-character separator, the remaining string length available for additional details is 11 characters for Mastercard and 14 characters for Visa. This is enough for a value such as `Cosmotour* to the Moon`. ``` {#codeblock_m2w_r5h_23c .language-json} { "payment": { "amount": 1000, "currency": "EUR", "description": "Payout" }, "general": { "project_id": 91348, "payment_id": "135113521354", "signature": "iehD3ZeW3CM7aGfmdgfjdgneHbCmronMpXom1b/ot1HvOGMV+CT8LA==" }, "customer": { "id": "16061313", "ip_address": "93.47.230.225", "first_name": "John", "last_name": "Doe" }, "sender": { "descriptor": "Cosmotour* to the Moon" // merchant details }, "card": { "save": false, "pan": "4314220000000056" } } ``` **Parent topic:**[Additional capabilities](en_Gate_Additional_capabilities.md) --- # Gate API {#gate_api} **Up one level:** [Gate](en_Gate_Integration_About.md) { "openapi": "3.0.2", "info": { "title": "Gate API", "description": "Ecommpay Gate public API is an interface for merchants to perform operations and retrieve operation information", "version": "3.34.5" }, "servers": [ { "url": "https://api.ecommpay.com" } ], "paths": { "/v2/payment/card/sale": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/sale", "description": "Request for purchase from the customer's card", "operationId": "POST_v2-payment-card-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "card", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "card": { "$ref": "#/components/schemas/CardInfoForSaleAuth" }, "token_data": { "$ref": "#/components/schemas/TokenData" }, "customer": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfoCard" }, { "type": "object", "properties": {}, "required": [ "email", "phone", "screen_res" ] } ] }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfoForCard" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "sender": { "$ref": "#/components/schemas/SenderInfoSale" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/AddendumInitialCard" }, "acs_return_url": { "$ref": "#/components/schemas/ACSReturnUrl" }, "authentication_data": { "$ref": "#/components/schemas/AuthenticationData" }, "recipient": { "$ref": "#/components/schemas/RecipientForCard" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "installment": { "$ref": "#/components/schemas/Installment" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/sale/saved": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/sale/saved", "description": "Request for purchase from the customer's saved card", "operationId": "POST_v2-payment-card-sale-saved", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "saved_account_id" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfoCard" }, { "type": "object", "properties": {}, "required": [ "email", "phone", "screen_res" ] } ] }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfoForCard" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "installment": { "$ref": "#/components/schemas/Installment" }, "saved_account_id": { "type": "integer", "description": "The identifier associated with the corresponding payment instrument in the payment platform" }, "cvv": { "type": "string", "pattern": "^[0-9]{3,4}$", "description": "Card Verification Value/Code (CVV/CVC), intended to verify that the customer has the card in their possession" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "sender": { "$ref": "#/components/schemas/SenderInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/AddendumInitialCard" }, "acs_return_url": { "$ref": "#/components/schemas/ACSReturnUrl" }, "authentication_data": { "$ref": "#/components/schemas/AuthenticationData" }, "recipient": { "$ref": "#/components/schemas/RecipientForCard" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/sale/token": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/sale/token", "operationId": "POST_v2-payment-card-sale-token", "description": "Request for purchase from the customer's card by using its token", "requestBody": { "description": "Payment by token", "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "token" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfoCard" }, { "type": "object", "properties": {}, "required": [ "email", "phone", "screen_res" ] } ] }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfoForCard" }, "token": { "description": "Card token received from the payment platform", "type": "string", "minLength": 1, "maxLength": 255 }, "cvv": { "description": "Card Verification Value/Code (CVV/CVC), intended to verify that the customer has the card in their possession", "type": "string", "pattern": "^[0-9]{3,4}$" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "sender": { "$ref": "#/components/schemas/SenderInfoSale" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/AddendumInitialCard" }, "acs_return_url": { "$ref": "#/components/schemas/ACSReturnUrl" }, "authentication_data": { "$ref": "#/components/schemas/AuthenticationData" }, "recipient": { "$ref": "#/components/schemas/RecipientForCard" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "installment": { "$ref": "#/components/schemas/Installment" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/card/auth": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/auth", "description": "Request for holding funds on the customer's card. The holding of funds can be captured or cancelled by merchant request or automatically if it is specified in merchant project", "operationId": "POST_v2-payment-card-auth", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "card", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "card": { "$ref": "#/components/schemas/CardInfoForSaleAuth" }, "token_data": { "$ref": "#/components/schemas/TokenData" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "customer": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfoCard" }, { "type": "object", "properties": {}, "required": [ "email", "phone", "screen_res" ] } ] }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfoForCard" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/AddendumInitialCard" }, "acs_return_url": { "$ref": "#/components/schemas/ACSReturnUrl" }, "authentication_data": { "$ref": "#/components/schemas/AuthenticationData" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "installment": { "$ref": "#/components/schemas/Installment" }, "sender": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/auth/saved": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/auth/saved", "description": "Request for holding funds on the customer's saved card", "operationId": "POST_v2-payment-card-auth-saved", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "saved_account_id" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfoCard" }, { "type": "object", "properties": {}, "required": [ "email", "phone", "screen_res" ] } ] }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfoForCard" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "saved_account_id": { "type": "integer", "description": "The identifier associated with the corresponding payment instrument in the payment platform" }, "cvv": { "type": "string", "pattern": "^[0-9]{3,4}$", "description": "Card Verification Value/Code (CVV/CVC), intended to verify that the customer has the card in their possession" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/AddendumInitialCard" }, "acs_return_url": { "$ref": "#/components/schemas/ACSReturnUrl" }, "authentication_data": { "$ref": "#/components/schemas/AuthenticationData" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "installment": { "$ref": "#/components/schemas/Installment" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/auth/token": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/auth/token", "operationId": "POST_v2-payment-card-auth-token", "description": "Request for holding funds on the customer's saved card by using its token", "requestBody": { "description": "DMS first step by token", "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "token" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfoCard" }, { "type": "object", "properties": {}, "required": [ "email", "phone", "screen_res" ] } ] }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfoForCard" }, "token": { "description": "Card token received from the payment platform", "type": "string", "minLength": 1, "maxLength": 255 }, "cvv": { "description": "Card Verification Value/Code (CVV/CVC), intended to verify that the customer has the card in their possession", "type": "string", "pattern": "^[0-9]{3,4}$" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/AddendumInitialCard" }, "acs_return_url": { "$ref": "#/components/schemas/ACSReturnUrl" }, "authentication_data": { "$ref": "#/components/schemas/AuthenticationData" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "installment": { "$ref": "#/components/schemas/Installment" }, "sender": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/card/capture": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/capture", "description": "Request for debit of the previously held funds on the customer's card", "operationId": "POST_v2-payment-card-capture", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "type": "object", "properties": { "amount": { "type": "integer", "description": "Payment amount, can be equal to, less or more than in the initial auth request. If the amount is less or more than in the auth request a decremental or incremental operation is created automatically" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency in ISO 4217 alpha-3 format, must match the currency in the initial auth request" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description or comment" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" } } }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/Addendum" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/incremental": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/incremental", "description": "Request for changing the amount of payment after holding, before confirm", "operationId": "POST_v2-payment-card-incremental", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoCard" }, "payment": { "type": "object", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Amount to increment" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency in ISO 4217 alpha-3 format, must be same with currency in auth request" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" } }, "required": [ "currency", "amount" ] }, "addendum": { "$ref": "#/components/schemas/Addendum" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/cancel": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/cancel", "description": "Request to cancel the holding of funds on the customer's card", "operationId": "POST_v2-payment-card-cancel", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "type": "object", "properties": { "amount": { "type": "integer", "description": "Payment amount, can be equal to or less than in the initial auth request. If the amount is less than in the auth request a decremental operation is created automatically" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency in ISO 4217 alpha-3 format, must match the currency in auth request" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description or comment" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" } } }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/Addendum" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/account_verification": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/account_verification", "description": "Request for card verification without performing actual withdrawal", "operationId": "POST_v2-payment-card-account-verification", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "card", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "card": { "$ref": "#/components/schemas/CardInfo" }, "token_data": { "$ref": "#/components/schemas/TokenData" }, "customer": { "type": "object", "description": "Object that contains customer details", "allOf": [ { "$ref": "#/components/schemas/CustomerInfoNameValidation" }, { "type": "object", "required": [ "id" ] } ] }, "payment": { "$ref": "#/components/schemas/AccountVerificationPaymentInfoForCard" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "acs_return_url": { "$ref": "#/components/schemas/ACSReturnUrl" }, "authentication_data": { "$ref": "#/components/schemas/AuthenticationData" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "sender": { "$ref": "#/components/schemas/Descriptor" }, "merchant": { "allOf": [ { "$ref": "#/components/schemas/MerchantInfo" }, { "$ref": "#/components/schemas/Descriptor" } ] } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/account_verification/token": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/account_verification/token", "description": "Request for card verification by token without performing actual withdrawal", "operationId": "POST_v2-payment-card-account-verification-by-token", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "token" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "type": "object", "description": "Object that contains customer details", "allOf": [ { "$ref": "#/components/schemas/CustomerInfoNameValidation" }, { "type": "object", "required": [ "id" ] } ] }, "payment": { "$ref": "#/components/schemas/AccountVerificationPaymentInfoForCard" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "acs_return_url": { "$ref": "#/components/schemas/ACSReturnUrl" }, "authentication_data": { "$ref": "#/components/schemas/AuthenticationData" }, "token": { "description": "Card token received from the payment platform", "type": "string", "minLength": 1, "maxLength": 255 }, "cvv": { "description": "Card Verification Value/Code (CVV/CVC), intended to verify that the customer has the card in their possession", "type": "string", "pattern": "^[0-9]{3,4}$" }, "card": { "type": "object", "properties": { "stored_card_type": { "$ref": "#/components/schemas/StoredCardType" } } }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "sender": { "$ref": "#/components/schemas/Descriptor" }, "merchant": { "allOf": [ { "$ref": "#/components/schemas/MerchantInfo" }, { "$ref": "#/components/schemas/Descriptor" } ] } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/recurring": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/recurring", "description": "Request to perform regular COF payment from the customer's card", "operationId": "POST_v2-payment-card-recurring", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "type": "object", "description": "Object that contains customer details", "allOf": [ { "$ref": "#/components/schemas/CustomerInfo" }, { "type": "object", "required": [ "id" ] } ] }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfoRecurring" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "recurring_id": { "description": "Identifier of the created credential-on-file (COF) purchase. Can be used to perform and manage COF purchasesentifier received from the payment platform", "type": "integer" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "sender": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/recurring/update": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/recurring/update", "description": "Request to update or change recurring payment conditions", "operationId": "POST_v2-payment-card-recurring-update", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringUpdateInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/recurring/cancel": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/recurring/cancel", "description": "Request to cancel recurring payment", "operationId": "POST_v2-payment-card-recurring-cancel", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/merchant_auth": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/merchant_auth", "description": "Request for performing a customer authentication by the payment system on merchant's request", "operationId": "POST_v2-payment-card-merchant_auth", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/MerchantAuthGeneralInfo" }, "confirmation_code": { "type": "string", "minLength": 1, "description": "Authentication confirmation code entered by a customer" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/3ds_check_iframe": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/3ds_check_iframe", "operationId": "POST_v2-payment-card-3ds_check_iframe", "description": "Request to check enrolled card after show iframe", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo3DS" }, "threeds_completion_indicator": { "description": "Indicator that specifies whether the message acknowledging the receipt of the customer's device information was received within 10 seconds after the iframe element was closed. If the acknowledgement was received within 10 seconds, pass `true`; if not, pass `false`", "type": "boolean" }, "md": { "type": "string", "minLength": 1, "description": "Merchant state data. The content of this field must be passed unchanged and without assumptions about its content" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/3ds_result": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/3ds_result", "description": "Request to continue payment processing after 3-D Secure authentication", "operationId": "POST_v2-payment-card-3ds_result", "requestBody": { "content": { "application/json": { "schema": { "oneOf": [ { "required": [ "general", "cres" ], "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo3DS" }, "cres": { "type": "string", "minLength": 1, "description": "Challenge response - the parameter containing the information about customer's 3‑D Secure 2 authentication result sent in the message from the Access Control Server" }, "md": { "type": "string", "minLength": 1, "description": "Merchant state data received from the payment platform in the callback. The content of this field must be passed unchanged and without assumptions about its content" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } }, { "required": [ "general", "pares" ], "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo3DS" }, "pares": { "type": "string", "minLength": 1, "description": "Payer Authentication Response - the parameter containing the information about customer's 3‑D Secure 1 authentication result sent in the message from the Access Control Server" }, "md": { "type": "string", "description": "Merchant state data received from the payment platform in the callback. The content of this field must be passed unchanged and without assumptions about its content" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } }, { "x-stoplight": { "id": "5ifn7agerbe31" } } ], "type": "object" } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/refund": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/refund", "description": "* Request for full or partial refund to the customer's card.\n* Refund is requested in the same currency that the payment was performed.\n* The refund amount can be less than or equal to the amount of the initial payment. The partial refund amount is specified in the parameter `amount`.\n* If the refund amount is not specified in the request, the full amount of the initial payment is refunded", "operationId": "POST_v2-payment-card-refund", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/Addendum" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/payout": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/payout", "description": "Request to credit funds to the customer's card", "operationId": "POST_v2-payment-card-payout", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "card", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "card": { "$ref": "#/components/schemas/CardInfoLight" }, "customer": { "$ref": "#/components/schemas/CustomerInfoPayout" }, "sender": { "$ref": "#/components/schemas/SenderInfoPayout" }, "recipient": { "type": "object", "properties": { "country": { "maxLength": 2, "pattern": "^[A-Z]{2}$", "type": "string", "description": "Country code of recipient" }, "address": { "maxLength": 99, "type": "string", "description": "Recipient address" }, "city": { "maxLength": 25, "type": "string", "description": "Name of recipient's address city" }, "state": { "maxLength": 3, "pattern": "^[A-Z]+$", "type": "string", "description": "State code of recipient" }, "first_name": { "type": "string", "maxLength": 255, "description": "Customer first name" }, "last_name": { "type": "string", "maxLength": 255, "description": "Customer last name" } } }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "$ref": "#/components/schemas/CryptoPayment" }, { "type": "object", "description": "Object that contains payment details", "properties": { "purpose": { "type": "string", "maxLength": 12, "description": "Payment purpose code—the parameter is populated if specification of payment purpose is mandatory in issuer country" } } } ] }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "merchant": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/card/payout/token": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/card/payout/token", "description": "Request to credit funds to the customer's card by using its token", "operationId": "POST_v2-payment-card-payout-token", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "token" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoPayout" }, "sender": { "$ref": "#/components/schemas/SenderInfoPayout" }, "recipient": { "type": "object", "properties": { "country": { "maxLength": 2, "pattern": "^[A-Z]{2}$", "type": "string", "description": "Country code of recipient" }, "address": { "maxLength": 99, "type": "string", "description": "Recipient address" }, "city": { "maxLength": 25, "type": "string", "description": "Name of recipient's address city" }, "state": { "maxLength": 3, "pattern": "^[A-Z]+$", "type": "string", "description": "State code of recipient" }, "first_name": { "type": "string", "maxLength": 255, "description": "Customer first name" }, "last_name": { "type": "string", "maxLength": 255, "description": "Customer last name" } } }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "type": "object", "description": "Object that contains payment details", "properties": { "purpose": { "type": "string", "maxLength": 12, "description": "Payment purpose code—the parameter is populated if specification of payment purpose is mandatory in issuer country" } } } ] }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "token": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Card token received from the payment platform" }, "card": { "type": "object", "properties": { "card_holder": { "type": "string", "maxLength": 255, "pattern": "^[a-zA-Z0-9\\s\\-.']+$", "description": "Name of the cardholder as specified on the payment card" } } }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "merchant": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/individual/payout": { "post": { "tags": [ "Card payments" ], "summary": "/v2/payment/individual/payout", "description": "Request to credit funds to a customer's card by using P2P scheme", "operationId": "POST_v2-payment-individual-payout", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "card", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "card": { "$ref": "#/components/schemas/CardInfoLight" }, "customer": { "$ref": "#/components/schemas/CustomerInfoPayout" }, "sender": { "$ref": "#/components/schemas/SenderInfo" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/customer/card/bytoken": { "post": { "tags": [ "Token operations" ], "summary": "/v2/customer/card/bytoken", "description": "Request for retrieving the saved customer's payment account details by customer's card token in specific project", "operationId": "POST_v2-customer-card-bytoken", "requestBody": { "content": { "application/json": { "schema": { "required": [ "customer", "token" ], "type": "object", "properties": { "customer": { "$ref": "#/components/schemas/CustomerGeneralInfo" }, "token": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Card token received from the payment platform" } }, "description": "Object that contains parameters for receiving of the customer's payment account in the project" } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "required": [ "account", "signature" ], "type": "object", "properties": { "signature": { "type": "string", "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)." }, "account": { "$ref": "#/components/schemas/SavedAccount" } } } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/customer/card/tokenize": { "post": { "tags": [ "Token operations" ], "summary": "/v2/customer/card/tokenize", "description": "Request for the token generation of a customer's card", "operationId": "POST_v2-customer-card-tokenize", "requestBody": { "content": { "application/json": { "schema": { "required": [ "customer", "card" ], "type": "object", "properties": { "customer": { "$ref": "#/components/schemas/TokenizeCustomerInfo" }, "card": { "$ref": "#/components/schemas/CardInfoForTokenize" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/customer/card/token/revoke": { "post": { "tags": [ "Token operations" ], "summary": "/v2/customer/card/token/revoke", "description": "Request for revoking token.", "operationId": "POST_v2-customer-card-token-revoke", "requestBody": { "content": { "application/json": { "schema": { "required": [ "token", "customer" ], "type": "object", "properties": { "token": { "type": "string", "minLength": 1, "maxLength": 255 }, "customer": { "$ref": "#/components/schemas/CustomerGeneralInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/clarification": { "post": { "tags": [ "Additional information submission" ], "summary": "/v2/payment/clarification", "description": "Request to pass the parameters required to make a payment and missed in the previously sent payment request", "operationId": "POST_v2-clarification", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "additional_data" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfoClarification" }, "additional_data": { "$ref": "#/components/schemas/AdditionalData" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/payout/registration": { "post": { "tags": [ "Payment Page payouts" ], "summary": "/v2/payment/payout/registration", "description": "Register payout payment", "operationId": "POST_v2-payment-payout-registration", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "required": [ "payment_id", "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "payment_id": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Identifier of the payment, must be unique within project. Any letters, digits, and symbols in UTF-8 encoding can be used" }, "merchant_callback_url": { "type": "string", "minLength": 1, "maxLength": 255, "description": "URL for handling request callbacks. This parameter should be passed when callbacks for a request need to be sent to an address that is different from that specified by default (for information about callbacks and how to use them, see [Handling callbacks](https://developers.ecommpay.com/en/en_platform_callbacks.html)). Example: `https://cosmoshop.earth/specialorder`" }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } } }, "customer": { "required": [ "id", "ip_address", "email" ], "type": "object", "properties": { "id": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Customer identifier unique within the project" }, "email": { "type": "string", "maxLength": 255, "format": "email", "description": "Customer email address" }, "phone": { "pattern": "^[0-9]{4,24}$", "type": "string", "description": "Customer's phone number, can be 4 to 24 digits long" }, "ip_address": { "type": "string", "maxLength": 255, "format": "ip-address", "description": "Customer IP address" } } }, "payment": { "required": [ "amount", "currency" ], "type": "object", "description": "Object that contains payment details", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[:_A-Z0-9]{3,27}$", "description": "Payment currency in the ISO 4217 alpha-3 format" } } } } } } } }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/verification-of-payee/create": { "post": { "tags": [ "Verification of Payee Service" ], "summary": "/v2/verification-of-payee/create", "description": "Request for verification of payee", "operationId": "POST_v2-verification-of-payee-create", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "account" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "description": "Object that contains customer details", "allOf": [ { "$ref": "#/components/schemas/CustomerInfoBase" }, { "type": "object", "properties": {}, "required": [ "id" ] } ] }, "account": { "description": "Object that contains account details", "allOf": [ { "$ref": "#/components/schemas/AccountBankPayoutInfo" }, { "type": "object", "properties": {}, "required": [ "customer_name", "number" ] } ] } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/verification-of-payee/result": { "post": { "tags": [ "Verification of Payee Service" ], "summary": "/v2/verification-of-payee/result", "description": "Request for verification of payee result", "operationId": "POST_v2-verification-of-payee-result", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "vop" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "vop": { "required": [ "id" ], "type": "object", "properties": { "id": { "type": "integer", "description": "Id of vop" } }, "description": "Object that contains vop fields." } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/session/applepay": { "post": { "tags": [ "Apple Pay", "sync" ], "summary": "/v2/session/applepay", "description": "Request for receiving the Apple Pay payment session", "operationId": "POST_v2-session-applepay", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/SessionGeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/ApplePaySessionPaymentInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/SessionResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/applepay/sale": { "post": { "tags": [ "Apple Pay" ], "summary": "/v2/payment/applepay/sale", "description": "Request to debit funds from the customer's card via Apple Pay", "operationId": "POST_v2-payment-applepay-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "etoken" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "etoken": { "$ref": "#/components/schemas/ETokenInfoLight" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "recipient": { "$ref": "#/components/schemas/RecipientForCard" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "sender": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/applepay/auth": { "post": { "tags": [ "Apple Pay" ], "summary": "/v2/payment/applepay/auth", "description": "Request for performing authentication from the customer's card via Apple Pay", "operationId": "POST_v2-payment-applepay-auth", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "etoken" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "etoken": { "$ref": "#/components/schemas/ETokenInfoLight" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "sender": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/applepay/capture": { "post": { "tags": [ "Apple Pay" ], "summary": "/v2/payment/applepay/capture", "description": "Request for performing a customer capture from the customer's card via Apple Pay", "operationId": "POST_v2-payment-applepay-capture", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/applepay/recurring": { "post": { "tags": [ "Apple Pay" ], "summary": "/v2/payment/applepay/recurring", "description": "Request to perform recurring payment from the customer's card via Apple Pay", "operationId": "POST_v2-payment-applepay-recurring", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/applepay/recurring/cancel": { "post": { "tags": [ "Apple Pay" ], "summary": "/v2/payment/applepay/recurring/cancel", "description": "Request to cancel recurring payment from the customer's card via Apple Pay", "operationId": "POST_v2-payment-applepay-recurring-cancel", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/applepay/refund": { "post": { "tags": [ "Apple Pay" ], "summary": "/v2/payment/applepay/refund", "description": "Request to perform refund payment from the customer's card via Apple Pay", "operationId": "POST_v2-payment-applepay-refund", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/applepay/account_verification": { "post": { "tags": [ "Apple Pay" ], "summary": "/v2/payment/applepay/account_verification", "description": "Request for card verification without performing actual withdrawal via Apple Pay", "operationId": "POST_v2-payment-applepay-account-verification", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "etoken" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoNameValidation" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/AccountVerificationPaymentInfo" }, "etoken": { "$ref": "#/components/schemas/ETokenInfoLight" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/applepay/cancel": { "post": { "tags": [ "Apple Pay" ], "summary": "/v2/payment/applepay/cancel", "description": "Request to cancel the holding of funds on the customer's card via Apple Pay", "operationId": "POST_v2-payment-applepay-cancel", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/CancelPaymentInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/atm/{payment_method}/sale": { "post": { "tags": [ "ATM" ], "summary": "/v2/payment/atm/{payment_method}/sale", "operationId": "POST_v2-payment-atm-payment-method-sale", "description": "Request to debit funds from the customer's card by means of ATMs of the supported banks", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "description": "Payment initiation request", "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "return_url" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "account": { "$ref": "#/components/schemas/AccountBankPurchaseInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "card": { "$ref": "#/components/schemas/CardInfoLight" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/atm/{payment_method}/payout": { "post": { "tags": [ "ATM" ], "summary": "/v2/payment/atm/{payment_method}/payout", "operationId": "POST_v2-payment-atm-payment-method-payout", "description": "Request for payout to the customer's card by means of ATMs of the supported banks", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "description": "Payout initiation request", "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "account" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoPayout" }, "account": { "$ref": "#/components/schemas/AccountAtmPayoutInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "card": { "$ref": "#/components/schemas/CardInfoLight" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/bancontact/sale": { "post": { "tags": [ "Bancontact" ], "summary": "/v2/payment/bancontact/sale", "description": "Request for payment by using Bancontact", "operationId": "POST_v2-payment-bancontact-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/bancontact/refund": { "post": { "tags": [ "Bancontact" ], "summary": "/v2/payment/bancontact/refund", "description": "Request for refund by using Bancontact", "operationId": "POST_v2-payment-bancontact-refund", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" } } } } }, "required": true }, "responses": { "200": { "description": "Success", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/banks/{payment_method}/sale": { "post": { "tags": [ "Banks" ], "summary": "/v2/payment/banks/{payment_method}/sale", "operationId": "POST_v2-payment-banks-payment-method-sale", "description": "Request to debit funds from the customer's card in one of the supported banks", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "description": "Payment initiation request", "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "account": { "$ref": "#/components/schemas/AccountBankPurchaseInfo" }, "payment": { "$ref": "#/components/schemas/PaymentBanksInfo" }, "return_url": { "oneOf": [ { "$ref": "#/components/schemas/ReturnUrl" }, { "type": "string", "description": "URL to which customer is redirected after payment performing", "minLength": 1 } ] }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/banks/{payment_method}/payout": { "post": { "tags": [ "Banks" ], "summary": "/v2/payment/banks/{payment_method}/payout", "operationId": "POST_v2-payment-banks-payment-method-payout", "description": "Request to credit funds to the customer's card in one of the supported banks", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "description": "Payout initiation request", "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "account" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoPayout" }, "account": { "$ref": "#/components/schemas/AccountBankPayoutInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "card": { "$ref": "#/components/schemas/CardInfoLight" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/banks/{payment_method}/refund": { "post": { "tags": [ "Banks" ], "summary": "/v2/payment/banks/{payment_method}/refund", "operationId": "POST_v2-payment-banks-payment-method-refund", "description": "Request for refund to the customer's card in one of the supported banks", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "description": "Refund initiation request", "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/bank-transfer/{payment_method}/sale": { "post": { "tags": [ "Bank Transfer" ], "summary": "/v2/payment/bank-transfer/{payment_method}/sale", "description": "Request for transferring of funds from the customer's bank account in one of the supported banks", "operationId": "POST_v2-payment-bank-transfer-method-sale", "parameters": [ { "name": "payment_method", "in": "path", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/BankTransferCustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "account": { "$ref": "#/components/schemas/AnotherAccountBankInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/bank-transfer/{payment_method}/payout": { "post": { "tags": [ "Bank Transfer" ], "summary": "/v2/payment/bank-transfer/{payment_method}/payout", "description": "Request for transferring of funds to the customer's bank account in one of the supported banks", "operationId": "POST_v2-payment-bank-transfer-method-payout", "parameters": [ { "name": "payment_method", "in": "path", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoPayout" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "sender": { "$ref": "#/components/schemas/SenderInfo" }, "account": { "$ref": "#/components/schemas/AccountBankInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "additional_data": { "$ref": "#/components/schemas/AdditionalData" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/bank-transfer/{payment_method}/refund": { "post": { "tags": [ "Bank Transfer" ], "summary": "/v2/payment/bank-transfer/{payment_method}/refund", "description": "Request for refund transferring to the customer's bank account in one of the supported banks", "operationId": "POST_v2-payment-bank-transfer-varying-method-refund", "parameters": [ { "name": "payment_method", "in": "path", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" }, "account": { "$ref": "#/components/schemas/AccountBankRefundInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/blik/sale": { "post": { "tags": [ "Blik" ], "summary": "/v2/payment/blik/sale", "description": "Request for payment through blik payment method", "operationId": "POST_v2-payment-blik-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/blik/refund": { "post": { "tags": [ "Blik" ], "summary": "/v2/payment/blik/refund", "description": "Request for refund through blik payment method", "operationId": "POST_v2-payment-blik-refund", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/bnpl/humm/sale": { "post": { "tags": [ "BNPL" ], "summary": "/v2/payment/bnpl/humm/sale", "description": "BNPL sale", "operationId": "POST_v2-payment-bnpl-humm-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment", "customer" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoBnplSale" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/cup/union/sale": { "post": { "tags": [ "China UnionPay" ], "summary": "/v2/payment/cup/union/sale", "description": "Request to debit funds from the customer's account in China UnionPay system by using CUP payment method union", "operationId": "POST_v2-payment-cup-union-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "return_url" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "return_url": { "$ref": "#/components/schemas/CupReturnUrl" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/unionpay/refund": { "post": { "tags": [ "China UnionPay" ], "summary": "/v2/payment/unionpay/refund", "operationId": "POST_v2-payment-unionpay-refund", "description": "Request for refund through the UnionPay payment method", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/directdebit/{payment_method}/sale": { "post": { "tags": [ "Direct debit" ], "summary": "/v2/payment/directdebit/{payment_method}/sale", "description": "Request for purchase with mandate registrations", "operationId": "POST_v2-payment-directdebit-payment_method-sale", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": false, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringRequiredInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/directdebit/{payment_method}/contract/registration": { "post": { "tags": [ "Direct debit" ], "summary": "/v2/payment/directdebit/{payment_method}/contract/registration", "description": "Request to mandate registrations without making payment", "operationId": "POST_v2-payment-directdebit-payment_method-contract-registration", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": false, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfoDirectDebit" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringRequiredInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/directdebit/{payment_method}/recurring": { "post": { "tags": [ "Direct debit" ], "summary": "/v2/payment/directdebit/{payment_method}/recurring", "description": "Request to perform recurring payment from the customer's directdebit account", "operationId": "POST_v2-payment-directdebit-recurring", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "recurring_id": { "description": "Identifier of the created credential-on-file (COF) purchase. Can be used to perform and manage COF purchases", "type": "integer" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/directdebit/{payment_method}/recurring/update": { "post": { "tags": [ "Direct debit" ], "summary": "/v2/payment/directdebit/{payment_method}/recurring/update", "description": "Request to perform recurring payment update info", "operationId": "POST_v2-payment-directdebit-recurring-update", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringUpdateInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/directdebit/{payment_method}/recurring/cancel": { "post": { "tags": [ "Direct debit" ], "summary": "/v2/payment/directdebit/{payment_method}/recurring/cancel", "description": "Request to perform recurring payment cancel", "operationId": "POST_v2-payment-directdebit-recurring-cancel", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/recurring/info": { "post": { "tags": [ "Requests for recurring" ], "summary": "/v2/payment/recurring/info", "description": "Request to get info about recurring payment conditions", "operationId": "POST_v2-payment-recurring-info", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "type": "object", "description": "Object that contains general request details", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "required": [ "project_id", "signature" ] }, "recurring": { "type": "object", "description": "Object that contains the identifier of the created credential-on-file (COF) purchase. Can be used to perform and manage COF purchases", "properties": { "id": { "type": "integer", "minimum": 1, "description": "Unique identifier of the recurring payment in the payment platform" } }, "required": [ "id" ] } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/RecurringInfoSuccess" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/refund": { "post": { "tags": [ "Requests for refunding specific payments" ], "summary": "/v2/payment/refund", "description": "* Request for full or partial refund to the customer's payment method.\n* Refund is requested in the same currency that the payment was performed.\n* The refund amount can be less than or equal to the amount of the initial payment. The partial refund amount is specified in the parameter `amount`.\n* If the refund amount is not specified in the request, the full amount of the initial payment is refunded", "operationId": "POST_v2-payment-refund", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "addendum": { "$ref": "#/components/schemas/Addendum" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/googlepay/sale": { "post": { "tags": [ "Google Pay" ], "summary": "/v2/payment/googlepay/sale", "description": "Request to debit funds from the customer's card via Google Pay", "operationId": "POST_v2-payment-googlepay-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "etoken" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "etoken": { "$ref": "#/components/schemas/GooglePayETokenInfoLight" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "recipient": { "$ref": "#/components/schemas/RecipientForCard" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "sender": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/googlepay/auth": { "post": { "tags": [ "Google Pay" ], "summary": "/v2/payment/googlepay/auth", "description": "Request for performing authentication from the customer's card via Google Pay", "operationId": "POST_v2-payment-googlepay-auth", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "etoken" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "etoken": { "$ref": "#/components/schemas/GooglePayETokenInfoLight" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "sender": { "$ref": "#/components/schemas/Descriptor" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/googlepay/capture": { "post": { "tags": [ "Google Pay" ], "summary": "/v2/payment/googlepay/capture", "description": "Request for performing a customer capture from the customer's card via Google Pay", "operationId": "POST_v2-payment-googlepay-capture", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/googlepay/recurring": { "post": { "tags": [ "Google Pay" ], "summary": "/v2/payment/googlepay/recurring", "description": "Request to perform recurring payment from the customer's card via Google Pay", "operationId": "POST_v2-payment-googlepay-recurring", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/googlepay/recurring/cancel": { "post": { "tags": [ "Google Pay" ], "summary": "/v2/payment/googlepay/recurring/cancel", "description": "Request to cancel recurring payment from the customer's card via Google Pay", "operationId": "POST_v2-payment-googlepay-recurring-cancel", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/googlepay/refund": { "post": { "tags": [ "Google Pay" ], "summary": "/v2/payment/googlepay/refund", "description": "Request to perform refund payment from the customer's card via Google Pay", "operationId": "POST_v2-payment-googlepay-refund", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/payment/googlepay/account_verification": { "post": { "tags": [ "Google Pay" ], "summary": "/v2/payment/googlepay/account_verification", "description": "Request for card verification without performing actual withdrawal via Google Pay", "operationId": "POST_v2-payment-googlepay-account-verification", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "etoken" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoNameValidation" }, "payment": { "$ref": "#/components/schemas/AccountVerificationPaymentInfo" }, "etoken": { "$ref": "#/components/schemas/GooglePayETokenInfoLight" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "avs_data": { "$ref": "#/components/schemas/AvsInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/googlepay/cancel": { "post": { "tags": [ "Google Pay" ], "summary": "/v2/payment/googlepay/cancel/etoken", "description": "Request to cancel the holding of funds on the customer's card via Google Pay", "operationId": "POST_v2-payment-googlepay-cancel", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/CancelPaymentInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/online-banking/{payment_method}/sale": { "post": { "tags": [ "Online banking" ], "summary": "/v2/payment/online-banking/{payment_method}/sale", "description": "Request for payment from customer's online bank account in one of the supported banks", "operationId": "POST_v2-payment-online-banking-payment_method-sale", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "receipt_data": { "$ref": "#/components/schemas/ReceiptData" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "recurring_register": { "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment", "type": "boolean" }, "additional_data": { "$ref": "#/components/schemas/AdditionalData" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/online-banking/{payment_method}/refund": { "post": { "tags": [ "Online banking" ], "summary": "/v2/payment/online-banking/{payment_method}/refund", "description": "Request for refund to the customer's online bank account in one of the supported banks", "operationId": "POST_v2-payment-online-banking-payment_method-refund", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/pix/sale": { "post": { "tags": [ "Pix" ], "summary": "/v2/payment/pix/sale", "description": "Request for payment through the Pix payment method", "operationId": "POST_v2-payment-pix-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" } } } } } }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/pix/payout": { "post": { "tags": [ "Pix" ], "summary": "/v2/payment/pix/payout", "description": "Request for payout through the Pix payment method", "operationId": "POST_v2-payment-pix-payout", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "account": { "$ref": "#/components/schemas/AccountBankInfo" } } } } } }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/invoice/create": { "post": { "tags": [ "Payment links" ], "summary": "/v2/payment/invoice/create", "description": "Request to create an invoice payment", "operationId": "POST_v2-payment-invoice-create", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfoInvoice" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoInvoice" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfoInvoice" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "operation_type": { "type": "string", "enum": [ "sale", "auth", "contract registration" ], "description": "Operation type for customer to pay. Default is sale." }, "send_email": { "type": "boolean", "description": "Send automatic email to customer or not" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" }, "recipient": { "$ref": "#/components/schemas/RecipientForCard" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Payload parsing or data structure error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/invoice/card/token/create": { "post": { "tags": [ "Payment links" ], "summary": "/v2/payment/invoice/card/token/create", "operationId": "POST_v2-payment-invoice-card-token-create", "description": "Create invoice payment by token", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "token" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfoInvoice" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoInvoice" }, "payment": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfoInvoiceByToken" }, { "$ref": "#/components/schemas/CryptoPayment" } ] }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recipient": { "$ref": "#/components/schemas/RecipientForCard" }, "token": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Token of the customer's card in Gate" }, "operation_type": { "type": "string", "enum": [ "sale", "auth" ], "description": "Operation type for customer to pay. Default is sale." }, "send_email": { "type": "boolean", "description": "Send automatic email to customer or not" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "booking_info": { "$ref": "#/components/schemas/BookingInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Payload parsing or data structure error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/invoice/cancel": { "post": { "tags": [ "Payment links" ], "summary": "/v2/payment/invoice/cancel", "operationId": "POST_v2-payment-invoice-cancel", "description": "Request to cancel invoice payment", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfoInvoice" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Payload parsing or data structure error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/skrill/sale": { "post": { "tags": [ "Skrill" ], "summary": "/v2/payment/skrill/sale", "description": "Request for payment through the Skrill payment method", "operationId": "POST_v2-payment-skrill-sale", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "return_url" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/skrill/1-tap": { "post": { "tags": [ "Skrill" ], "summary": "/v2/payment/skrill/1-tap", "description": "Request for OneClick payment through the Skrill payment method", "operationId": "POST_v2-payment-skrill-1-tap", "requestBody": { "content": { "application/json": { "schema": { "type": "object", "required": [ "general", "customer", "payment", "recurring" ], "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/skrill/recurring/update": { "post": { "tags": [ "Skrill" ], "summary": "/v2/payment/skrill/recurring/update", "description": "Request to update or change recurring conditions of the payment through the Skrill payment method", "operationId": "POST_v2-payment-skrill-recurring-update", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringUpdateInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/skrill/recurring/cancel": { "post": { "tags": [ "Skrill" ], "summary": "/v2/payment/skrill/recurring/cancel", "description": "Request to cancel recurring payment through the Skrill payment method", "operationId": "POST_v2-payment-skrill-recurring-cancel", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/skrill/payout": { "post": { "tags": [ "Skrill" ], "summary": "/v2/payment/skrill/payout", "description": "Request for payout through the Skrill payment method", "operationId": "POST_v2-payment-skrill-payout", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "account", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/SkrillCustomerInfo" }, "account": { "$ref": "#/components/schemas/AccountInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/skrill/refund": { "post": { "tags": [ "Skrill" ], "summary": "/v2/payment/skrill/refund", "description": "Request for refund through the Skrill payment method", "operationId": "POST_v2-payment-skrill-refund", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "account", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/SkrillCustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "account": { "$ref": "#/components/schemas/AccountInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/sale": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/sale", "description": "Request for payment via methods that support e-wallets", "operationId": "POST_v2-payment-wallet-paymentmethod-sale", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "account": { "type": "object", "allOf": [ { "$ref": "#/components/schemas/AccountInfo" }, { "type": "object", "properties": { "customer_name": { "type": "string", "description": "Account owner full name" } } } ] }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "addendum": { "$ref": "#/components/schemas/AddendumData" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/auth": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/auth", "description": "First step DMS for APS", "operationId": "POST_v2-payment-wallet-paymentmethod-auth", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "return_url" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "account": { "$ref": "#/components/schemas/AccountInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/capture": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/capture", "description": "First step DMS for APS", "operationId": "POST_v2-payment-wallet-paymentmethod-capture", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "properties": { "amount": { "type": "integer", "description": "Payment amount, can be equal to, less or more than in the initial auth request. If the amount is less or more than in the auth request a decremental or incremental operation is created automatically" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency in ISO 4217 alpha-3 format, must match the currency in the initial auth request" } } } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/cancel": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/cancel", "description": "Cancel step DMS for APS", "operationId": "POST_v2-payment-wallet-paymentmethod-cancel", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/CancelPaymentInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" }, "callback": { "$ref": "#/components/schemas/CallbackInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/sale/1click": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/sale/1click", "description": "Request for OneClick payment through the payment method that supports such payments by using e-wallets", "operationId": "POST_v2-payment-wallet-payment-method-sale-1click", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "saved_account_id" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoWithId" }, "account": { "$ref": "#/components/schemas/AccountInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringInfo" }, "saved_account_id": { "type": "integer" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/recurring": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/recurring", "description": "Request to perform regular payment from the customer's e-wallet", "operationId": "POST_v2-payment-wallet-payment-method-recurring", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment", "customer", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoWalletRecurring" }, "account": { "$ref": "#/components/schemas/AccountInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/1-tap": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/1-tap", "description": "Request for OneClick payment through the payment method that supports such payments by using e-wallets", "operationId": "POST_v2-payment-wallet-payment-method-1-tap", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/recurring/update": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/recurring/update", "description": "Request to update or change recurring conditions of the payment through the payment method that supports such payments by using e-wallets", "operationId": "POST_v2-payment-recurring-update", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringUpdateInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/recurring/cancel": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/recurring/cancel", "description": "Request to cancel recurring payments through the payment method that supports such payments by using e-wallets", "operationId": "POST_v2-payment-recurring-cancel", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "recurring": { "$ref": "#/components/schemas/RecurringIdInfo" }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/refund": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/refund", "description": "Request for refund to the customer's e-wallet", "operationId": "POST_v2-payment-wallet-refund", "parameters": [ { "name": "payment_method", "in": "path", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "merchant": { "$ref": "#/components/schemas/MerchantInfo" }, "payment": { "$ref": "#/components/schemas/RefundPaymentInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/wallet/{payment_method}/payout": { "post": { "tags": [ "Wallet" ], "summary": "/v2/payment/wallet/{payment_method}/payout", "description": "Request for payout via methods that use e-wallets", "operationId": "POST_v2-payment-wallet-payment-method-payout", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "customer", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfoPayout" }, "account": { "$ref": "#/components/schemas/AccountInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" }, "return_url": { "$ref": "#/components/schemas/ReturnUrl" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/customer/info": { "post": { "tags": [ "Requests for customer details" ], "summary": "/v2/customer/info", "description": "Request for retrieving customer data by customer identifier within the project", "operationId": "POST_v2-customer-info", "requestBody": { "content": { "application/json": { "schema": { "required": [ "customer" ], "type": "object", "properties": { "customer": { "$ref": "#/components/schemas/CustomerGeneralInfo" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "required": [ "customer", "signature" ], "type": "object", "properties": { "customer": { "required": [ "ip_address", "project_id" ], "type": "object", "properties": { "id": { "type": "string", "description": "Customer identifier unique within the project" }, "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`" }, "country": { "pattern": "^[A-Z]{2}$", "type": "string", "description": "Customer country code in the ISO 3166-1 alpha-2 format" }, "phone": { "pattern": "^[0-9]{4,24}$", "type": "string", "description": "Customer's phone number, can be 4 to 24 digits long" }, "email": { "maxLength": 255, "type": "string", "description": "Customer email address", "format": "email" }, "day_of_birth": { "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "type": "string", "description": "Customer's date of birth. This parameter is specified in DD-MM-YYYY format. Example: `12-12-1990`" }, "first_name": { "maxLength": 255, "type": "string", "description": "Customer first name" }, "last_name": { "maxLength": 255, "type": "string", "description": "Customer last name" }, "address": { "maxLength": 255, "type": "string", "description": "Customer address" }, "zip": { "maxLength": 255, "type": "string", "description": "Customer address postal code" }, "city": { "maxLength": 256, "type": "string", "description": "Name of customer's address city" }, "street": { "maxLength": 256, "type": "string", "description": "Street of customer address" }, "browser": { "maxLength": 512, "type": "string", "description": "A string that identifies the customer browser information" }, "ip_address": { "maxLength": 255, "type": "string", "description": "Customer IP address, both IPv4 and IPv6 are supported", "format": "ip-address" }, "billing": { "type": "object", "properties": { "country": { "pattern": "^[A-Z]{2}$", "type": "string", "description": "Country code of the customer's billing address in ISO 3166-1 alpha-2 format" }, "region": { "type": "string", "description": "The region or state of the customer's billing address" }, "city": { "type": "string" }, "address": { "type": "string" }, "postal": { "type": "string" } }, "description": "Billing info" }, "created_at": { "type": "string" } } }, "signature": { "type": "string", "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)." } } } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/customer/saved_account/list": { "post": { "tags": [ "Requests for customer details" ], "summary": "/v2/customer/saved_account/list", "description": "Request for retrieving saved customer's payment instruments in the project", "operationId": "POST_v2-customer-saved_account-list", "requestBody": { "content": { "application/json": { "schema": { "required": [ "customer", "payment_method" ], "type": "object", "properties": { "customer": { "$ref": "#/components/schemas/CustomerGeneralInfo" }, "payment_method": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Identifier of the payment method in the payment platform" } }, "description": "Object that contains customer details" } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "required": [ "accounts", "signature" ], "type": "object", "properties": { "signature": { "type": "string", "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)." }, "accounts": { "type": "array", "description": "Array that contains information about the customer's saved payment accounts", "items": { "$ref": "#/components/schemas/SavedAccount" } } } } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorItems" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/customer/saved_account/delete": { "post": { "tags": [ "Requests for customer details" ], "summary": "/v2/customer/saved_account/delete", "description": "Request for removal of saved card or other saved account of the customer", "operationId": "POST_v2-customer-saved_account-delete", "requestBody": { "content": { "application/json": { "schema": { "required": [ "customer", "saved_account_id" ], "type": "object", "properties": { "customer": { "$ref": "#/components/schemas/CustomerGeneralInfo" }, "saved_account_id": { "type": "integer", "description": "The ID of the customer's saved account received from the payment platform" }, "payment_method": { "type": "string", "default": "card", "enum": [ "card" ], "description": "Payment method type for saved accounts set" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "required": [ "message", "status" ], "type": "object", "properties": { "status": { "type": "string", "description": "Status of removing of the saved used account" }, "message": { "type": "string", "description": "Notification of the removal of the saved customer's account" } }, "description": "" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorItems" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/payment/status/request": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/payment/status/request", "description": "Request for clarifying the status and other data of the payment by ProjectId and RequestId", "requestBody": { "content": { "application/json": { "schema": { "required": [ "project_id", "request_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer" }, "request_id": { "maxLength": 100, "type": "string" }, "signature": { "maxLength": 255, "type": "string" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/TransactionStatusResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "404": { "description": "Payment not found", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-internal": false } }, "/v2/payment/status": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/payment/status", "description": "Request for retrieving the status and other data of the payment. Keep in mind that depending on the individual settings of the project the format of the response may vary. Presented below is the default format of the response", "operationId": "POST_v2-payment-status", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "destination": { "type": "string", "enum": [ "merchant", "terminal" ], "default": "merchant", "description": "Destination of notification (terminal, merchant, etc.)" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/PaymentStatusResponse" } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorItems" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/info/available-methods/{payment_direction}/list": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/info/available-methods/{payment_direction}/list", "description": "Returns availability of requested payment methods", "operationId": "POST_v2-info-available-methods-list", "parameters": [ { "name": "payment_direction", "in": "path", "description": "Payment direction", "required": true, "schema": { "type": "string", "enum": [ "payin", "payout" ] } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "description": "Object that contains general request details", "type": "object", "required": [ "project_id", "signature" ], "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } } }, "payment_method_list": { "type": "array", "description": "Array of elements containing information about requested payment methods", "items": { "type": "object", "required": [ "payment_method" ], "properties": { "payment_method": { "type": "string", "description": "Payment method code" } } } } } } } }, "required": false }, "responses": { "200": { "description": "Success", "content": { "application/json": { "schema": { "type": "array", "description": "Array that contains information about payment methods", "items": { "type": "object", "properties": {} } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorItems" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/info/banks/bycountry": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/info/banks/bycountry", "operationId": "POST_v2-info-banks-bycountry", "description": "Returns bank list broken down by country", "requestBody": { "content": { "application/json": { "schema": { "required": [ "project_id", "signature", "country" ], "type": "object", "properties": { "project_id": { "type": "integer" }, "signature": { "type": "string" }, "country": { "type": "string", "format": "[A-Z][A-Z][A-Z]" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "type": "array", "items": { "type": "object", "properties": {} } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/info/banks/byaggregator": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/info/banks/byaggregator", "operationId": "POST_v2-info-banks-byaggregator", "description": "Returns bank list broken down by aggregator", "requestBody": { "content": { "application/json": { "schema": { "required": [ "project_id", "aggregator_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer" }, "aggregator_id": { "type": "integer" }, "signature": { "type": "string", "minLength": 1 } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "type": "array", "items": { "type": "object", "properties": {} } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/info/banks/bypaymentmethod": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/info/banks/bypaymentmethod", "operationId": "POST_v2-info-banks-bypaymentmethod", "description": "Returns bank list broken down by payment method", "requestBody": { "content": { "application/json": { "schema": { "required": [ "project_id", "payment_method_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer" }, "payment_method_id": { "type": "integer" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Currency in ISO 4217 alpha-3 format" }, "type": { "type": "string" }, "signature": { "type": "string", "minLength": 1 } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "type": "array", "items": { "type": "object", "properties": {} } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/info/banks/byprovider": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/info/banks/byprovider", "operationId": "POST_v2-info-banks-byprovider", "description": "Returns bank list broken down by provider", "requestBody": { "content": { "application/json": { "schema": { "required": [ "project_id", "provider_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer" }, "provider_id": { "type": "integer" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Currency in ISO 4217 alpha-3 format" }, "type": { "type": "string" }, "signature": { "type": "string", "minLength": 1 } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "type": "array", "items": { "type": "object", "properties": {} } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/info/banks/{payment_method}/{operationType}/list": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/info/banks/{payment_method}/{operationType}/list", "operationId": "POST_v2-info-banks-payment-method-operationType-list", "description": "Request to retrieve the list of banks available for the specified payment method and operation type", "parameters": [ { "name": "payment_method", "in": "path", "description": "Payment method", "required": true, "schema": { "type": "string" } }, { "name": "operationType", "in": "path", "description": "Operation type", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentBanksInfo" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "type": "array", "items": { "type": "object", "properties": {} } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/info/banks/{parentMethod}/{childMethod}/{operationType}/list": { "post": { "tags": [ "Requests for information", "sync" ], "summary": "/v2/info/banks/{parentMethod}/{childMethod}/{operationType}/list", "operationId": "POST_v2-info-banks-parentMethod-childMethod-operationType-list", "description": "Request to retrieve the list of banks available for the specified payment method and operation type (for groupped methods)", "parameters": [ { "name": "parentMethod", "in": "path", "required": true, "schema": { "type": "string" } }, { "name": "childMethod", "in": "path", "required": true, "schema": { "type": "string" } }, { "name": "operationType", "in": "path", "required": true, "schema": { "type": "string" } } ], "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "payment": { "$ref": "#/components/schemas/PaymentInfo" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "type": "array", "items": { "type": "object", "properties": {} } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "x-codegen-request-body-name": "request" } }, "/v2/recurring/retry-custom-schedule/save": { "post": { "tags": [ "Requests for recurring" ], "summary": "/v2/recurring/retry-custom-schedule/save", "description": "Request to save custom recurring retry schedule", "operationId": "POST_v2-recurring-retry-custom-schedule-save", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "interval_days" ], "type": "object", "properties": { "general": { "required": [ "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "description": "Object that contains general request details" }, "interval_days": { "type": "array", "minItems": 1, "maxItems": 10, "uniqueItems": true, "description": "The schedule by days when retry attempts for charging funds should be made", "items": { "type": "integer", "minimum": 1, "maximum": 10 } } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "required": [ "status" ], "type": "object", "properties": { "status": { "maxLength": 255, "type": "string" } } } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/recurring/retry-custom-schedule/info": { "post": { "tags": [ "Requests for recurring" ], "summary": "/v2/recurring/retry-custom-schedule/info", "description": "Request to get custom recurring retry schedule", "operationId": "POST_v2-recurring-retry-custom-schedule-info", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "required": [ "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "description": "Object that contains general request details" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "required": [ "project_id", "schedule" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of merchant project received from Ecommpay" }, "schedule": { "type": "object", "properties": { "interval_days": { "type": "array", "description": "The schedule by days when retry attempts for charging funds should be made", "items": { "type": "integer" } }, "status": { "type": "string", "enum": [ "active", "disabled" ] } } } } }, "examples": { "Example 1": { "value": { "project_id": 0, "schedule": { "interval_days": [ 1 ], "status": "active" } } } } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/recurring/retry-custom-schedule/disable": { "post": { "tags": [ "Requests for recurring" ], "summary": "/v2/recurring/retry-custom-schedule/disable", "description": "Request to disable custom recurring retry schedule", "operationId": "POST_v2-recurring-retry-custom-schedule-disable", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general" ], "type": "object", "properties": { "general": { "required": [ "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "description": "Object that contains general request details" } } } } }, "required": false }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "required": [ "status" ], "type": "object", "properties": { "status": { "maxLength": 255, "type": "string" } } } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/recurring/retry_stop": { "post": { "tags": [ "Requests for recurring" ], "summary": "/v2/recurring/retry_stop", "description": "Request for restrict retry operation", "operationId": "POST_v2-recurring-retry_stop", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "recurring", "trigger_operation_id" ], "type": "object", "properties": { "general": { "type": "object", "description": "Object that contains general request details", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "required": [ "project_id", "signature" ] }, "recurring": { "type": "object", "description": "Object that contains Identifier of the created credential-on-file (COF) purchase. Can be used to perform and manage COF purchasesentifier", "properties": { "id": { "type": "integer", "minimum": 1, "description": "Unique identifier of the recurring payment in the payment platform" } }, "required": [ "id" ] }, "trigger_operation_id": { "description": "Identifier of operation which initiated retry", "type": "integer" } } } } }, "required": false }, "responses": { "200": { "description": "OK" }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "403": { "description": "Access denied", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } } }, "components": { "schemas": { "AccountInfo": { "required": [ "number" ], "type": "object", "properties": { "number": { "type": "string", "maxLength": 100, "minLength": 1, "description": "Customer's account number. Example: `21312`" }, "save": { "type": "boolean", "default": false, "description": "Indicator specifying whether the customer's account details should be saved" } }, "description": "Object that contains the minimum required details of the customer's payment instrument - account/wallet/voucher etc." }, "AccountAtmPayoutInfo": { "description": "Object that contains account information for payout performing by using ATMs", "type": "object", "properties": { "bank_id": { "type": "integer", "minimum": 1, "description": "Bank identifier received from the payment platform" }, "customer_name": { "type": "string", "description": "Account owner full name", "minLength": 1 }, "branch": { "type": "string", "description": "Bank branch", "maxLength": 255 }, "number": { "type": "string", "description": "Customer's account number. Example: `21312`", "minLength": 1 }, "region_id": { "type": "integer", "minimum": 1, "description": "Region or state identifier of the bank branch location received from the payment platform. Example: `3`" }, "city": { "type": "string", "maxLength": 255, "description": "Bank branch city code" } }, "required": [ "bank_id", "region_id" ] }, "AccountBankInfo": { "description": "Object that contains the account details of bank which is used for payment processing", "allOf": [ { "$ref": "#/components/schemas/AccountInfo" }, { "type": "object", "properties": { "type": { "type": "string", "maxLength": 255, "description": "Account type." }, "bank_id": { "type": "integer", "minimum": 1, "description": "Bank identifier received from the payment platform. Example: `137" }, "customer_name": { "type": "string", "description": "First name and last name of the account holder. Example: `John Johnson`" }, "security_code": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Payment confirmation code. Some payment methods may require this parameter (depending on the methods themselves). Example: `852923" }, "swift_code": { "type": "string", "minLength": 8, "maxLength": 11, "description": "SWIFT bank identification code" }, "routing_number": { "type": "string", "maxLength": 255, "description": "Identifier of the bank in the transfer system" }, "routing_type": { "type": "string", "maxLength": 255, "description": "Type of bank transfer. Possible values: `ACH CODE`—for the USA, `BANK CODE`—for Honkong, `BSB CODE`—for Australia, `IFSC`—for India, `SORT CODE`—for Great Britain, `TRANSIT NUMBER`—for Canada, `BRANCH CODE`—for Brazil, `SWIFT`—for other countries that support this method." }, "iban": { "type": "string", "minLength": 5, "maxLength": 34, "description": "International bank account number" }, "bank_name": { "type": "string", "description": "Name of the financial institution that issued the card. Example: `CITIGROUP`" }, "bank_branch_name": { "type": "string", "description": "Name of the bank branch" }, "bank_branch_code": { "type": "string", "description": "Code of the bank branch" }, "bank_branch_city": { "type": "string", "description": "City of the bank branch's location" }, "bank_branch_address": { "type": "string", "description": "Address of bank branch" }, "bank_code": { "type": "string", "description": "International bank identifier (BIC or SWIFT) or, in certain countries, a specific code used by the national interbank clearing center. Example: `1234`" }, "fin": { "type": "string", "description": "Financial institution number" }, "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Country code in the ISO 3166-1 alpha-2 format" } } } ] }, "AccountBankPayoutInfo": { "description": "Object that contains the details of the customer's bank account for payout performing", "allOf": [ { "$ref": "#/components/schemas/AccountInfo" }, { "type": "object", "properties": { "bank_id": { "type": "integer", "minimum": 1, "description": "Bank identifier received from the payment platform" }, "customer_name": { "type": "string", "description": "Account owner full name", "minLength": 1 }, "branch": { "type": "string", "description": "Bank branch", "maxLength": 255 }, "number": { "type": "string", "description": "Customer's account number. Example: `21312`", "minLength": 1 }, "region_id": { "type": "integer", "minimum": 1, "description": "Region or state identifier of the bank branch location received from the payment platform. Example: `3`" }, "city": { "type": "string", "maxLength": 255, "description": "Bank branch city code" }, "bank_code": { "type": "string", "minLength": 1, "maxLength": 255, "description": "International bank identifier (BIC or SWIFT) or, in certain countries, a specific code used by the national interbank clearing center. Example: `1234`" }, "bank_address": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Address of bank location" }, "bik": { "type": "string", "minLength": 9, "maxLength": 9, "description": "Bank code on the Russian Federation" }, "bank_name": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Name of the financial institution that issued the card. Example: `CITIGROUP`" }, "branch_code": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Bank branch code" }, "native_customer_name": { "type": "string", "description": "Native account owner full name", "minLength": 1 } } } ] }, "AccountBankPurchaseInfo": { "type": "object", "properties": { "bank_id": { "type": "integer", "minimum": 0, "description": "Bank identifier received from the payment platform" }, "number": { "type": "string", "description": "Customer's account number. Example: `21312`", "minLength": 1 }, "bank_code": { "type": "string", "description": "International bank identifier (BIC or SWIFT) or, in certain countries, a specific code used by the national interbank clearing center. Example: `1234`" }, "customer_name": { "type": "string", "description": "Account owner full name", "minLength": 1 } }, "description": "Object that contains the details of the customer's bank account for payment performing" }, "AccountBankRefundInfo": { "type": "object", "properties": { "bank_id": { "type": "integer", "minimum": 0, "description": "Bank identifier received from the payment platform" }, "number": { "type": "string", "description": "Customer's account number. Example: `21312`", "minLength": 1 }, "customer_name": { "type": "string", "description": "Account owner full name", "minLength": 1 } }, "description": "Object that contains the details of the customer's bank account for refund performing" }, "AccountInfoAtMerchant": { "type": "object", "properties": { "additional": { "type": "string", "maxLength": 64, "description": "Additional information about the customer's account in free text such as its identifier" }, "date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date created account. Format: DD-MM-YYYY" }, "change_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date of the most recent change of account data, excluding password updates or resets. Format: DD-MM-YYYY" }, "pass_change_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date of the most recent password change or reset. Format: DD-MM-YYYY" }, "purchase_number": { "type": "integer", "maximum": 9999, "description": "Number of purchases made via the customer's account in the last 6 months, 4 characters maximum" }, "provision_attempts": { "type": "integer", "maximum": 999, "description": "Number of attempts to add a new card to a customer's account in the last 24 hours" }, "activity_day": { "type": "integer", "maximum": 999, "description": "Number of payment attempts in the last 24 hours" }, "activity_year": { "type": "integer", "maximum": 999, "description": "Number of payment attempts in the last 365 days" }, "payment_age": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Card record creation date. Format: DD-MM-YYYY" }, "suspicious_activity": { "type": "string", "pattern": "^0[1-2]$", "description": "Indicator specifying whether the merchant has experienced suspicious activity on the cardholder account. Possible values: `01` —no suspicious activity detected, `02`—suspicious activity detected" }, "auth_method": { "type": "string", "pattern": "^0[1-4]$", "description": "Indicator specifying how the customer was authenticated during their most recent login to the web service. Possible values: `01`—no authentication, `02`—logging in with authentication data kept on file by the merchant,`03`—logging in with the federated identity credentials (for example, Google Account or Facebook ID), `04`—logging in with the use of FIDO authenticator (Fast Identity Online)" }, "auth_time": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}\\d{2}:\\d{2}$", "description": "Date and time of the customer's most recent account login. Format: DD-MM-YYYYhh:mm. Example: `01-10-202213:12`" }, "auth_data": { "type": "string", "maxLength": 255, "description": "Additional login information in free text" }, "age_indicator": { "type": "string", "pattern": "^0[1-5]$", "description": "Number of days since the customer account was created. Possible values: `01`—guest checkout, `02`—the account was created at the moment of making a payment, `03`—fewer than 30 days, `04`—between 30 and 60 day, `05`—more than 60 days" }, "change_indicator": { "type": "string", "pattern": "^0[1-4]$", "description": "Number of days since the most recent change to the account, except for the password change or password reset. Possible values: `01`—the account was updated on the day when the payment was made, `02`—fewer than 30 days, `03`—between 30 and 60 days, `04`—more than 60 days" }, "pass_change_indicator": { "type": "string", "pattern": "^0[1-5]$", "description": "Number of days since the most recent password change or reset. Possible values: `01`—password was not changed or reset, `02`—password was changed or reset on the day when the payment was made, `03`—fewer than 30 days, `04`—between 30 and 60 days, `05`—more than 60 days" }, "payment_age_indicator": { "type": "string", "pattern": "^0[1-5]$", "description": "Number of days since the payment card details were saved to a customer's account. Possible values: 01—guest checkout, 02—card details were saved on the day when the payment was made, 03—fewer than 30 days, 04—between 30 and 60 days, 05—more than 60 days" } }, "description": "An object that contains account data in merchant's web service." }, "AccountOnlineBankingPayoutInfo": { "type": "object", "properties": { "number": { "type": "string", "maxLength": 100, "minLength": 1, "description": "Customer's account number. Example: `21312`" }, "bank_code": { "type": "string", "description": "International bank identifier (BIC or SWIFT) or, in certain countries, a specific code used by the national interbank clearing center. Example: `1234`" }, "clearinghouse": { "type": "string", "maxLength": 255, "minLength": 1, "description": "Registration country of the interbank clearing center used by the bank of the account holder. Example: `SWEDEN`" } }, "description": "Object that contains the account details for payout processing" }, "AccountVerificationPaymentInfo": { "required": [ "amount", "currency" ], "type": "object", "properties": { "amount": { "type": "integer", "minimum": 0, "maximum": 0, "description": "Payment amount in minor currency units, should be passed with zero value" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency code in ISO 4217 alpha-3 format" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description or comment" }, "debt_account": { "type": "string", "maxLength": 10, "description": "The number of the account designated to receive funds as part of the debt settlement purchases. Example: `an9876170i`" } }, "description": "Stub object that contains necessary details for payment instrument verification. Amount should be passed with zero value" }, "AccountVerificationPaymentInfoForCard": { "allOf": [ { "$ref": "#/components/schemas/AccountVerificationPaymentInfo" }, { "$ref": "#/components/schemas/CryptoPayment" }, { "type": "object", "description": "Stub object that contains necessary details for payment instrument verification. Amount should be passed with zero value", "properties": { "debt_account": { "type": "string", "maxLength": 10, "description": "The number of the account designated to receive funds as part of the debt settlement purchases. Example: `an9876170i`" } } }, { "$ref": "#/components/schemas/MotoInfo" } ] }, "ACSReturnUrl": { "type": "object", "properties": { "return_url": { "type": "string", "description": "Return url for authenticated status" }, "3ds_notification_url": { "type": "string", "description": "Url for callback from ACS" } } }, "AddendumData": { "type": "object", "properties": { "lodging": { "oneOf": [ { "$ref": "#/components/schemas/AddendumLodgingInitial" }, { "type": "array", "items": { "$ref": "#/components/schemas/AddendumLodgingInitial" } } ] }, "airlines": { "oneOf": [ { "$ref": "#/components/schemas/AddendumAirlines" }, { "type": "array", "items": { "$ref": "#/components/schemas/AddendumAirlines" } } ] }, "professional_services": { "oneOf": [ { "$ref": "#/components/schemas/AddendumProfessionalServices" }, { "type": "array", "items": { "$ref": "#/components/schemas/AddendumProfessionalServices" } } ] }, "retail": { "oneOf": [ { "$ref": "#/components/schemas/AddendumRetail" }, { "type": "array", "items": { "$ref": "#/components/schemas/AddendumRetail" } } ] } } }, "Addendum": { "type": "object", "properties": { "lodging": { "$ref": "#/components/schemas/AddendumLodging" } } }, "AddendumAirlines": { "required": [ "departure_airport", "departure_date", "departure_time", "ticket", "trip_leg" ], "type": "object", "properties": { "departure_date": { "type": "string", "maxLength": 10, "pattern": "^(?:\\d{2})(1[012]|0?[1-9])(3[01]|[12][0-9]|0?[1-9])$", "description": "Departure date in YYMMDD format" }, "departure_airport": { "type": "string", "maxLength": 3, "description": "Originating airport name’s standard abbreviation" }, "departure_time": { "type": "string", "maxLength": 4, "pattern": "^([0-1][0-9]|2[0-3])[0-5][0-9]$", "description": "Time of departure provided by the airline. Format: HHMM" }, "arrival_time": { "type": "string", "maxLength": 4, "pattern": "^([0-1][0-9]|2[0-3])[0-5][0-9]$", "description": "Arrival time provided by the airline: Format: HHMM" }, "endorsements_restr": { "type": "string", "maxLength": 20, "description": "" }, "exchange_ticket": { "type": "string", "maxLength": 15, "description": "Original ticket number replaced by a new ticket number" }, "ticket": { "$ref": "#/components/schemas/AddendumAirlinesTicket" }, "trip_leg": { "$ref": "#/components/schemas/AddendumAirlinesTripLeg" } } }, "AddendumAirlinesTicket": { "required": [ "customer_ref", "issuing_carrier", "passenger_name", "ticket_number" ], "type": "object", "properties": { "passenger_name": { "type": "string", "maxLength": 20, "description": "Name of the passenger to whom the ticket was issued" }, "ticket_number": { "type": "string", "maxLength": 15, "description": "Number on the ticket" }, "issuing_carrier": { "type": "string", "maxLength": 2, "description": "Standard abbreviation for the airline carrier issuing the ticket" }, "customer_ref": { "type": "string", "maxLength": 25, "description": "Number or code that identifies the customer or consumer." }, "travel_agency_code": { "type": "string", "maxLength": 8, "description": "Code assigned to the travel agency" }, "travel_agency_name": { "type": "string", "maxLength": 25, "description": "Name of the travel agency issuing the ticket" }, "restricted_ticket_indicator": { "type": "boolean", "description": "Identifier noting that the ticket purchased has some restriction associated with its use" }, "ticket_issue_date": { "type": "string", "maxLength": 10, "pattern": "^(3[01]|[12][0-9]|0?[1-9])-(1[012]|0?[1-9])-((?:19|20)\\d{2})$", "description": "Date in which the Ticket was Issued" }, "total_tax_amount": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Tax amount for a line item, specified in minor units of currency. Example: `1800`" } } }, "AddendumAirlinesTripLeg": { "required": [ "carrier_code", "destination_airport", "fare_bassis", "flight_number", "service_class", "stop_over_code" ], "type": "object", "properties": { "carrier_code": { "type": "string", "maxLength": 2, "description": "Standard abbreviation for the airline carrier" }, "service_class": { "type": "string", "maxLength": 1, "pattern": "^([F|J|Y|W])$", "description": "Service type (such as coach or first class)" }, "destination_airport": { "type": "string", "maxLength": 3, "description": "Destination airport name’s standard abbreviation" }, "stop_over_code": { "type": "boolean", "description": "Code indicating whether there was a direct or a non-direct flight or route on the same ticket number" }, "fare_bassis": { "type": "string", "maxLength": 6, "description": "Code that carriers assign to a particular ticket type, such as business class or discounted/nonrefundable" }, "flight_number": { "type": "string", "maxLength": 5, "description": "Number that the operating or marketing carrier assigned" } } }, "AddendumInitialCard": { "type": "object", "description": "Available to merchants with eligible MCCs", "properties": { "airlines": { "$ref": "#/components/schemas/AddendumAirlinesCard" }, "lodging": { "$ref": "#/components/schemas/AddendumLodgingInitial" } } }, "AddendumAirlinesCard": { "required": [ "ticket_number", "passenger_name", "customer_ref", "ticket_issuer_code", "ticket_issue_date", "trip_legs" ], "type": "object", "properties": { "ticket_number": { "type": "string", "maxLength": "15", "description": "Ticket number assigned by the issuer", "example": "1051426005635" }, "passenger_name": { "type": "string", "maxLength": "20", "description": "Full passenger name (name and last name, title if available)", "example": "EDDINGTON/ARTHUR MR" }, "ticket_issuer_code": { "type": "string", "maxLength": "2", "description": "IATA 2-character code of the airline that issued the ticket", "example": "AY" }, "ticket_issue_date": { "type": "string", "format": "date", "description": "Date of ticket issuance, in ISO 8601 (YYYY-MM-DD) format", "example": "2025-10-04" }, "customer_ref": { "type": "string", "maxLength": "25", "description": "Identifier of the passenger record in the reservation system", "example": "T7H3PD" }, "travel_agency_code": { "type": "string", "maxLength": "8", "description": "IATA-accreditation code assigned to a travel agency", "example": "2921540" }, "travel_agency_name": { "type": "string", "maxLength": "25", "description": "Name of the travel agency that issued the ticket", "example": "Deep Sky Tours" }, "restricted_ticket_indicator": { "type": "boolean", "description": "Indicator that specifies refund restrictions applied to the ticket, (i.e. the ticket is non-refundable or can be returned)", "example": true }, "computerized_reservation_system": { "type": "string", "maxLength": "4", "description": "Code of the computerised reservation system, may be needed for payments in Germany, (STRT – Start, PARS – TWA, DATS – Delta, SABR – Sabre, DALA – Covia-Apollo, BLAN – Dr. Blank, DERD – DER, TUID – TUI)", "example": "TUID" }, "total_fare_amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Total amount of the ticket", "example": 23500 }, "total_tax_amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Amount of all the taxes associated with the ticket", "example": 135 }, "total_fees_amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Amount of the fees associated with the ticket", "example": 1447 }, "trip_legs": { "required": [ "trip_leg1" ], "type": "object", "properties": { "trip_leg1": { "$ref": "#/components/schemas/AddendumAirlinesCardTripLeg" }, "trip_leg2": { "$ref": "#/components/schemas/AddendumAirlinesCardTripLeg" }, "trip_leg3": { "$ref": "#/components/schemas/AddendumAirlinesCardTripLeg" }, "trip_leg4": { "$ref": "#/components/schemas/AddendumAirlinesCardTripLeg" } } } } }, "AddendumAirlinesCardTripLeg": { "required": [ "flight_number", "carrier_code", "departure_airport", "departure_at", "destination_airport", "arrival_at", "stop_over_code", "service_class", "fare_bassis" ], "type": "object", "properties": { "flight_number": { "type": "string", "maxLength": "5", "description": "The flight number assigned by operating or marketing carrier. Airline carrier code must not be included", "example": "156" }, "carrier_code": { "type": "string", "maxLength": "2", "description": "2-character IATA carrier code", "example": "AY" }, "departure_airport": { "type": "string", "maxLength": "3", "description": "3-character IATA code of the departure airport", "example": "IVL" }, "departure_at": { "type": "string", "format": "date-time", "description": "Date and time of departure, in the YYYY-MM-DDThh:mm:ss±hh:mm format (according to ISO 8601)", "example": "2025-10-31T16:05:00+02:00" }, "destination_airport": { "type": "string", "maxLength": "3", "description": "3-character IATA code of the destination airport", "example": "PFO" }, "arrival_at": { "type": "string", "format": "date-time", "description": "Date and time of arrival, in the YYYY-MM-DDThh:mm:ss±hh:mm format (according to ISO 8601)", "example": "2025-10-31T20:15:00+02:00" }, "stop_over_code": { "type": "boolean", "description": "Indicates whether the flight is direct (no stopover) or non-direct (includes stopover)", "example": true }, "service_class": { "type": "string", "maxLength": "1", "description": "IATA code of service class (R – Supersonic, P – First Class Premium, F – First Class, A – First Class Discounted; J – Business Class Premium, C – Business Class, {D, I, Z} – Business Class Discounted; W – Economy/Coach Premium, {S, Y} – Economy/Coach, {B, H, K, L, M, N, Q, T, V, X} – Economy/Coach Discounted)", "example": "Y" }, "fare_bassis": { "type": "string", "maxLength": "6", "description": "Particular fare applied by the carrier", "example": "YE3MFI" }, "exchange_ticket": { "type": "string", "maxLength": "15", "description": "The original ticket number replaced by a new ticket number (if applicable)", "example": "3904082308998" }, "conjunct_ticket": { "type": "string", "maxLength": "15", "description": "The ticket that contains additional coupons on an itinerary that is more than four segments (if present)", "example": "6065511855011" }, "coupon_number": { "type": "string", "maxLength": "3", "pattern": "\\d", "description": "Number of a coupon assigned to the leg inside the ticket", "example": "1" }, "endorsements_restr": { "type": "string", "maxLength": "20", "description": "Added notation specifying any relevant information about restrictions, additional data, and endorsement information", "example": "No changes allowed" } } }, "AddendumLodging": { "type": "object", "properties": { "check_out_date": { "maxLength": 19, "pattern": "^(3[01]|[12][0-9]|0?[1-9])-(1[012]|0?[1-9])-((?:19|20)\\d{2})$", "type": "string", "description": "Customer's check-out date in the dd-mm-yyyy format. Example: `22-12-2019`" }, "room": { "type": "object", "properties": { "rate": { "maximum": 999999999999, "type": "integer", "description": "Daily room charges exclusive of taxes and fees. Is used to calculate base lodging cost. This psrsmeter is provided in minor units of currency. Example: `12`" }, "number_of_nights": { "maximum": 99, "minimum": 1, "type": "integer", "description": "Total number of nights for which a room was contracted during a lodging stay. Example: `10" } } }, "total_tax": { "maximum": 999999999999, "minimum": 0, "type": "number", "description": "Total amount of sales tax or value added tax (VAT) on the total purchase amount. This parameter is provided in minor units of the payment's currency" }, "charges": { "$ref": "#/components/schemas/AddendumLodgingCharges" } }, "description": "Available only if MCC is 3501-3999 or 7011" }, "AddendumLodgingCharges": { "type": "object", "properties": { "room_service": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of the room service charges. This parameter provided in minor units of currency" }, "bar_or_lounge": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of the lounge or bar charges. This parameter provided in minor units of currency" }, "transportation": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of the transportation charges. This parameter provided in minor units of currency" }, "gratuity": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of the gratuity charges. This parameter provided in minor units of currency" }, "conference_room": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of the charges associated with conference room use. This parameter provided in minor units of currency" }, "audio_or_visual": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of the audiovisual equipment charges. This parameter provided in minor units of currency" }, "banquet": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of the banquet charges. This parameter provided in minor units of currency" }, "internet_access": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of the Internet access charges. This parameter provided in minor units of currency" }, "early_departure": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount charged because of early departure. This parameter provided in minor units of currency" }, "phone": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of charges for all phone calls. This parameter provided in minor units of currency" }, "restaurant": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of all restaurant charges. This parameter provided in minor units of currency" }, "minibar": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of in-room “mini-bar” service charges. This parameter provided in minor units of currency" }, "gift_shop": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of all gift shop and specialty shop charges. This parameter provided in minor units of currency" }, "laundry_or_cleaning": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount of cleaning charges. This parameter provided in minor units of currency" }, "valet": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Charges associated with the use of valet services. This parameter provided in minor units of currency" }, "movie": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount charged for in-room movies. This parameter provided in minor units of currency" }, "business_center": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount charged for business center use and supplies. This parameter provided in minor units of currency" }, "health_club": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Amount charged for health club use and supplies. This parameter provided in minor units of currency" } } }, "AddendumLodgingInitial": { "required": [ "check_in_date", "check_out_date", "customer_service_toll_free_number", "fire_safety_act_indicator", "folio_number", "room" ], "type": "object", "properties": { "customer_service_toll_free_number": { "type": "string", "maxLength": 17, "description": "A toll-free phone number for the customer service of the booked hotel or other type of accommodation. Example: `18005553535`" }, "hotel_name": { "type": "string", "maxLength": 255, "description": "Name of the hotel or other type of accommodation where the customer is staying. Example:`Best Eastern`" }, "check_in_date": { "type": "string", "maxLength": 19, "pattern": "^(3[01]|[12][0-9]|0?[1-9])-(1[012]|0?[1-9])-((?:19|20)\\d{2})$", "description": "Customer's check-in date in the dd-mm-yyyy format. Example: `10-12-2019`" }, "check_out_date": { "type": "string", "maxLength": 19, "pattern": "^(3[01]|[12][0-9]|0?[1-9])-(1[012]|0?[1-9])-((?:19|20)\\d{2})$", "description": "Customer's check-out date in the dd-mm-yyyy format. Example: `22-12-2019`" }, "folio_number": { "type": "string", "maxLength": 25, "description": "Card acceptor’s internal invoice or billing ID reference number. Example: `56265655ABC`" }, "room": { "description": "Object with room details", "properties": { "tax": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "Tax amount information such as the daily room tax, occupancy tax, energy tax, and tourist tax amounts. Example: `25`" }, "rate": { "type": "integer", "maximum": 999999999999, "description": "Daily room charges exclusive of taxes and fees. this parameter is used to calculate base lodging cost and is provided in minor units of currency. Example: `12`" }, "number_of_nights": { "type": "integer", "minimum": 1, "maximum": 99, "description": "Total number of nights for which room was contracted during lodging stay" } }, "required": [ "rate" ] }, "fire_safety_act_indicator": { "type": "boolean", "description": "Facility complies with the Hotel and Motel Fire Safety Act of 1990 (PL101-391) or similar legislation" }, "guest_name": { "type": "string", "maxLength": 40, "description": "Customer full name" }, "guest_number": { "type": "string", "maxLength": 25, "description": "Number assigned to the lodging customer" }, "billing_adjustment": { "type": "string", "maxLength": 12, "description": "Additional charges incurred after the cardholder departure" }, "property_phone_number": { "type": "string", "maxLength": 17, "description": "Specific lodging property location by its local phone number" }, "no_show_indicator": { "type": "boolean", "description": "Customer did not show up after making lodging reservation" }, "prepaid_expenses": { "type": "integer", "maximum": 999999999999, "description": "Amount of deposit or other prepaid amounts for the lodging stay. This parameter is provided in minor units of currency." }, "total_tax": { "type": "number", "minimum": 0, "maximum": 999999999999, "description": "The amount of all the taxes associated with the lodging. Applicable only to the Visa, Visa Electron and Maestro cards. Not applicable for Mastercard. This parameter is provided in minor units of the payment's currency" }, "charges": { "$ref": "#/components/schemas/AddendumLodgingCharges" } }, "description": "Available only if MCC is 3501-3999 or 7011" }, "AddendumProfessionalServices": { "required": [ "admission_notice_url" ], "type": "object", "properties": { "admission_notice_url": { "type": "string", "description": "Admission notice url" } } }, "AddendumRetail": { "required": [ "goods", "quantity" ], "type": "object", "properties": { "goods": { "type": "string", "description": "Name goods" }, "quantity": { "type": "integer", "description": "Quantity goods" } } }, "AdditionalData": { "type": "object", "properties": { "avs_data": { "$ref": "#/components/schemas/AvsInfo" } }, "description": "Object that contains additional payment information submission for payment processing. The object can contain any objects requested by the payment platform as specified in the **clarification_fields** object" }, "AnotherAccountBankInfo": { "description": "Object that contains the account details of bank which is used for payment processing. Used when account number is not required.", "allOf": [ { "$ref": "#/components/schemas/AnotherAccountInfo" }, { "type": "object", "properties": { "type": { "type": "string", "maxLength": 255, "description": "Account type." }, "bank_id": { "oneOf": [ { "type": "string", "minLength": 1, "description": "Bank identifier received from the payment platform" }, { "type": "integer", "minimum": 1, "description": "Bank identifier" } ] }, "customer_name": { "type": "string", "description": "Bank account's owner full name" }, "security_code": { "type": "string", "minLength": 1, "maxLength": 255, "description": "First 2 digits of the password" }, "swift_code": { "type": "string", "minLength": 8, "maxLength": 11, "description": "SWIFT bank identification code" }, "routing_number": { "type": "string", "maxLength": 255, "description": "Bank account's routing number" }, "routing_type": { "type": "string", "maxLength": 255, "description": "Bank account's routing type" }, "iban": { "type": "string", "minLength": 5, "maxLength": 34, "description": "International bank account number" }, "bank_name": { "type": "string", "description": "Name of the financial institution that issued the card. Example: `CITIGROUP`" }, "bank_branch_name": { "type": "string", "description": "Bank branch name" }, "bank_branch_code": { "type": "string", "description": "Bank branch code" }, "bank_branch_city": { "type": "string", "description": "City of bank branch location" }, "bank_branch_address": { "type": "string", "description": "Address of bank branch location" }, "bank_code": { "type": "string", "description": "International bank identifier (BIC or SWIFT) or, in certain countries, a specific code used by the national interbank clearing center. Example: `1234`" }, "fin": { "type": "string", "description": "Financial institution number" }, "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Country code in the ISO 3166-1 alpha-2 format" } } } ] }, "AnotherAccountInfo": { "type": "object", "properties": { "number": { "type": "string", "maxLength": 100, "minLength": 1, "description": "Customer's account number. Example: `21312`" }, "save": { "type": "boolean", "default": false, "description": "Indicator specifying whether the customer's account details should be saved" } }, "description": "Object that contains the minimum required details of the customer's payment instrument - account/wallet/voucher etc. Used when account number is not required." }, "ApplePaySessionPaymentInfo": { "required": [ "amount", "currency" ], "type": "object", "properties": { "amount": { "type": "integer", "minimum": 0, "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency code in the ISO 4217 alpha-3 format" }, "customer_amount": { "type": "integer", "minimum": 0, "maximum": 10000000000000, "description": "Payment amount converted into the currency selected by the customer. This parameter is specified in minor units of currency" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description or comment for additional data analisys by using Dashboard" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" }, "best_before": { "type": "string", "format": "date-time", "description": "Payment expiration date in the date-time format according to the ISO 8601 standart" }, "challenge_indicator": { "type": "string", "pattern": "^0[1-9]$", "description": "Indicates whether the challenge flow is preferred. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "challenge_window": { "type": "string", "pattern": "^0[1-5]$", "description": "The dimensions of a window in which the authentication page opens. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "reorder": { "type": "string", "pattern": "^0[1-2]$", "description": "Indicates whether the customer is buying the merchandise or the service for the first time or it is a repeat purchase. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_purchase": { "type": "string", "pattern": "^0[1-2]$", "description": "Parameter specifying whether the current purchase is pre-ordered. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date when the preordered merchandise or service will be available in the DD-MM-YYYY format" }, "gift_card": { "$ref": "#/components/schemas/GiftCardInfo" }, "device_channel": { "type": "string", "pattern": "^0[1-3]$", "description": "Indicator that specifies the type of the interface through which the web service initiates the 3-D Secure authentication. By default, it is set to `02` (Browser-based). In specific cases that must be agreed upon and approved, the value of this parameter can be `01` (App-based) and `03` (3DS Requestor Initiated). If `01` or `03` value is passed when it was not initially agreed upon, the payment may get declined" } }, "description": "Object that contains payment details" }, "AuthenticationData": { "required": [ "xid" ], "type": "object", "properties": { "cavv": { "type": "string", "maxLength": 255, "description": "Cardholder authentication verification value. Mandatory if `authentication_status`=`Y` or `A`" }, "ds_operation_id": { "type": "string", "maxLength": 36, "description": "Operation identifier assigned by the Directory Server" }, "eci": { "type": "string", "enum": [ "00", "01", "02", "05", "06", "07" ], "description": "The electronic commerce indicator" }, "threeds_version": { "type": "string", "enum": [ "3ds_1", "3ds_2", "non_3ds" ], "description": "Indicator of the 3‑D Secure authentication" }, "xid": { "type": "string", "maxLength": 255, "description": "The operation identifier (Base64-encoded, 20 bytes in a decoded form)" }, "enrollement_status": { "type": "string", "enum": [ "Y", "N", "U" ], "description": "The enrollment response from the VERes message from the directory server ('Y','N','U'). Supported for 3D Secure 1" }, "authentication_status": { "type": "string", "enum": [ "Y", "U", "A" ], "description": "Customer's authentication status. Possible values: `Y`—the cardholder was successfully authenticated by their card issuer, `A`—the cardholder authentication was attempted, `U`—the card issuer was unavailable during the authentication attempt" }, "authentication_flow": { "type": "string", "enum": [ "Frictionless", "Challenge" ], "description": "The indicator of the flow that was used for the customer 3-D Secure 2 authentication on the merchant side within the operation being processed" }, "threeds_full_version": { "type": "string", "description": "The full version of the 3-D Secure protocol", "example": "2.3.1", "maxLength": 8, "minLength": 5, "pattern": "^(\\d{1,2})\\.(\\d{1,2})\\.(\\d{1,2})(\\.(\\d{1,2}))?$" }, "authentication_status_reason_code": { "type": "string", "description": "Reason code for `authentication_status`", "maxLength": 2, "minLength": 2, "example": "01" } }, "description": "Object that contains 3DS Authentication Data from merchant" }, "AvsInfo": { "required": [ "avs_post_code", "avs_street_address" ], "type": "object", "properties": { "avs_post_code": { "type": "string", "description": "Postal code of the customer. Example: `WS13 6LG`", "minLength": 1 }, "avs_street_address": { "type": "string", "description": "Address of the customer. Example: `4 Breadmarket Street`", "minLength": 1 } }, "description": "Object that contains customer details for verification by the Address Verification Service. For more information, see [AVS Check](https://developers.ecommpay.com/en/en_Gate_avs.html)" }, "BankTransferCustomerInfo": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfo" }, { "type": "object", "properties": { "building": { "type": "string", "maxLength": 255, "description": "Customer building number" } } } ] }, "BookingInfo": { "type": "object", "description": "Object that contains general booking details", "properties": { "bookers": { "type": "array", "description": "List of customers included in the booking", "additionalProperties": false, "uniqueItems": true, "items": { "type": "object", "description": "Object that contains booker details", "additionalProperties": false, "properties": { "first_name": { "maxLength": 255, "type": "string", "description": "First name of the customer provided at the time of booking. Example: `William`" }, "last_name": { "maxLength": 255, "type": "string", "description": "Last name of the customer provided at the time of booking. Example: `Herschel`" }, "email": { "maxLength": 255, "type": "string", "format": "email", "description": " Email provided at the time of booking. Example: `rsfellow@mail.com`" } } } }, "items": { "type": "array", "description": "List of services included in the booking", "additionalProperties": false, "uniqueItems": true, "items": { "type": "object", "description": "Object that contains the details of each service included in the booking", "additionalProperties": false, "properties": { "description": { "type": "string", "maxLength": 255, "description": "Description of the service included in the booking. Example: `VIP Arrival`" }, "start_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Starting date of the service included in the booking, in the DD-MM-YYYY format. Example: `12-08-2026`" }, "end_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Ending date of the service included in the booking, in the DD-MM-YYYY format. Example: `12-08-2026`" } } } }, "start_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Starting date of the booked service, in the DD-MM-YYYY format. Example: `12-08-2026`" }, "end_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Ending date of the booked service, in the DD-MM-YYYY format. Example: `13-08-2026`" }, "description": { "type": "string", "maxLength": 255, "description": "Free-form description of the booked service. Example: `Siders music festival full pass`" }, "total": { "type": "integer", "description": "The total cost of the booking in minor units of currency. Value cannot be`0`. Example: `200000`" }, "pax": { "type": "integer", "description": "Number of people per booking. Value cannot be `0`. Example: `4`" }, "reference": { "type": "string", "maxLength": 255, "description": " Booking reference, which can be the URL, the name of the booked service, or its code in the merchant's web service. Example: `musicfestlink`" }, "id": { "type": "string", "maxLength": 255, "description": "Identifier of the booking, unique in the merchant's web service. Example: `83`" } } }, "CallbackInfo": { "type": "object", "properties": { "delay": { "type": "integer", "description": "Delay time for sending callbacks, in seconds. Example: `42`", "minimum": 0, "maximum": 600 }, "force_disable": { "type": "boolean", "description": "Indicator for disabling callbacks. Possible values: `true`—for disabling callbacks with information about the given payment, and `false`—for enabling these callbacks" } }, "description": "Object that contains additional callback sending conditions" }, "CancelPaymentInfo": { "type": "object", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Refund amount in minor currency units" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Currency code in ISO-4217 alpha-3 format" }, "description": { "type": "string", "maxLength": 255, "description": "Refund description or comment" } }, "description": "Object that contains information about refund" }, "CardInfo": { "required": [ "month", "pan", "year" ], "type": "object", "properties": { "pan": { "type": "string", "format": "pan", "maxLength": 32, "description": "For cards - the number of the payment card used for payment. Specified as is, without masked characters, spaces, or other separators. For network tokens - the token without masked characters, spaces, or other separator. Example:`4314220000000056`" }, "year": { "type": "integer", "minimum": 2020, "maximum": 9999, "description": "For cards - the year of the card's expiration date. For network tokens - the year of the token's expiration date (according to the Gregorian calendar)" }, "month": { "type": "integer", "minimum": 1, "maximum": 12, "description": "For cards - the month of the card's expiration date. For network tokens - the month of the token's expiration date" }, "card_holder": { "type": "string", "maxLength": 255, "pattern": "^[a-zA-Z0-9\\s\\-.']+$", "description": "Name of the cardholder as specified on the payment card" }, "cvv": { "type": "string", "pattern": "^[0-9]{3,4}$", "description": "Card Verification Value/Code (CVV/CVC), intended to verify that the customer has the card in their possession" }, "security_code": { "type": "string", "pattern": "^[0-9]{2}$", "description": "First 2 digits of the password." }, "save": { "type": "boolean", "description": "Indicator specifying whether the customer's account details should be saved" }, "stored_card_type": { "$ref": "#/components/schemas/StoredCardType" } }, "description": "Object that contains the information about customer's card that is used for payment. Contains parameters to specify card details or the information about the network token associated with the card" }, "CardInfoForSaleAuth": { "required": [ "month", "pan", "year" ], "type": "object", "properties": { "pan": { "type": "string", "format": "pan", "maxLength": 32, "description": "For cards - the number of the payment card used for payment. Specified as is, without masked characters, spaces, or other separators. For network tokens - the token without masked characters, spaces, or other separator. Example:`4314220000000056`" }, "year": { "type": "integer", "minimum": 2020, "maximum": 9999, "description": "For cards - the year of the card's expiration date. For network tokens - the year of the token's expiration date (according to the Gregorian calendar)" }, "month": { "type": "integer", "minimum": 1, "maximum": 12, "description": "For cards - the month of the card's expiration date. For network tokens - the month of the token's expiration date" }, "card_holder": { "type": "string", "maxLength": 255, "pattern": "^[a-zA-Z0-9\\s\\-.']+$", "description": "Name of the cardholder as specified on the payment card" }, "cvv": { "type": "string", "pattern": "^[0-9]{3,4}$", "description": "Card Verification Value/Code (CVV/CVC), intended to verify that the customer has the card in their possession" }, "security_code": { "type": "string", "pattern": "^[0-9]{2}$", "description": "First 2 digits of the password" }, "save": { "type": "boolean", "description": "Indicator specifying whether the customer's account details should be saved" }, "stored_card_type": { "$ref": "#/components/schemas/StoredCardType" } }, "description": "Object that contains the information about customer's card that is used for payment. Contains parameters to specify card details or the information about the network token associated with the card" }, "CardInfoForTokenize": { "required": [ "month", "pan", "year" ], "type": "object", "properties": { "pan": { "type": "string", "format": "pan", "maxLength": 32, "description": "Number of the payment card used for payment. Specified as is, without masked characters, spaces, or other separators. Example:`4314220000000056`" }, "year": { "type": "integer", "minimum": 2020, "maximum": 9999, "description": "Year of the card's expiration date, intended to indicate the last valid year for card usage" }, "month": { "type": "integer", "minimum": 1, "maximum": 12, "description": "Month of the card's expiration date, intended to indicate the last valid month for card usage" }, "card_holder": { "type": "string", "maxLength": 255, "pattern": "^[a-zA-Z0-9\\s\\-.']+$", "description": "Name of the cardholder as specified on the payment card" } }, "description": "Object that contains the customer's card details that is used for tokenize" }, "CardInfoLight": { "required": [ "pan" ], "type": "object", "properties": { "pan": { "type": "string", "format": "pan", "maxLength": 32, "description": "Number of the payment card used for payment. Specified as is, without masked characters, spaces, or other separators. Example:`4314220000000056`" }, "year": { "type": "integer", "minimum": 2020, "maximum": 9999, "description": "Year of the card's expiration date, intended to indicate the last valid year for card usage" }, "month": { "type": "integer", "minimum": 1, "maximum": 12, "description": "Month of the card's expiration date, intended to indicate the last valid month for card usage" }, "issue_year": { "type": "integer", "maximum": 9999, "description": "Year of issuing date of the card" }, "issue_month": { "type": "integer", "minimum": 1, "maximum": 12, "description": "Month of issuing date of the card" }, "card_holder": { "type": "string", "maxLength": 255, "pattern": "^[a-zA-Z0-9\\s\\-.']+$", "description": "Name of the cardholder as specified on the payment card" }, "cvv": { "type": "string", "pattern": "^[0-9]{3,4}$", "description": "Card Verification Value/Code (CVV/CVC), intended to verify that the customer has the card in their possession" }, "save": { "type": "boolean", "description": "Indicator specifying whether the customer's account details should be saved" }, "stored_card_type": { "$ref": "#/components/schemas/StoredCardType" } }, "description": "Object that contains the customer's card details that is used for payment" }, "CupReturnUrl": { "allOf": [ { "$ref": "#/components/schemas/ReturnUrl" }, { "type": "object", "required": [ "success" ] } ] }, "CustomerGeneralInfo": { "required": [ "id", "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "id": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Customer identifier unique within the project" }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "description": "Object that contains general customer details in merchant project" }, "CustomerInfo": { "description": "Object that contains customer details", "allOf": [ { "$ref": "#/components/schemas/CustomerInfoBase" }, { "type": "object", "required": [ "ip_address" ] } ] }, "CustomerInfoBase": { "type": "object", "properties": { "id": { "type": "string", "maxLength": 255, "description": "Customer identifier unique within the project" }, "identification_level": { "type": "string", "maxLength": 255, "description": "Indicator specifying whether the customer is trusted; provided by the merchant. Example: `1`—the customer is trusted" }, "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Customer's country code in the ISO 3166-1 alpha-2 format. Example: `GB`" }, "city": { "type": "string", "maxLength": 256, "description": "Name of customer's address city" }, "state": { "type": "string", "maxLength": 256, "description": "Name of the region (state, province, or other administrative subdivision type) of the customer's address. Example: `Greater London`" }, "phone": { "type": "string", "pattern": "^[0-9]{4,24}$", "description": "Customer's phone number, can be 4 to 24 digits long" }, "iin": { "type": "string", "maxLength": 255, "description": "Customer's individual identification number. Issued by the government or other official authority. Can be used for identity verification, regulatory compliance, and fraud prevention checks" }, "home_phone": { "type": "string", "pattern": "^[0-9]{4,24}$", "description": "Customer's home phone number, can be 4 to 24 digits long" }, "work_phone": { "type": "string", "pattern": "^[0-9]{4,24}$", "description": "Customer's work phone number, can be 4 to 24 digits long" }, "save": { "type": "boolean", "description": "Indicator specifying whether the customer's account details should be saved" }, "account_save": { "type": "boolean", "description": "Indicator specifying whether the customer's account details should be saved" }, "day_of_birth": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Customer's date of birth. This parameter is specified in DD-MM-YYYY format. Example: `12-12-1990`" }, "person_type": { "type": "string", "maxLength": 255, "description": "Type of the customer as a legal person, for example, a company or an individual, used for compliance" }, "birthplace": { "type": "string", "maxLength": 255, "description": "Name of the customer's birthplace (e.g., town, city, or other settlement type). Example: `London`" }, "first_name": { "type": "string", "maxLength": 255, "description": "First name of the customer. Example: `Jane`" }, "middle_name": { "type": "string", "maxLength": 255, "description": "Middle, second, or patronymic name of the customer. Example: `Mary`" }, "last_name": { "type": "string", "maxLength": 255, "description": "Last name of the customer. Example: `Smith`" }, "email": { "type": "string", "maxLength": 255, "format": "email", "description": "Email address of the customer. The string consists of a local-part and a domain name, separated by the `@` symbol. Example: `helen@example.com`." }, "browser": { "type": "string", "maxLength": 512, "description": "Name and version of the customer's browser used to access the web service. Can be used to identify the customer environment for risk and fraud analysis" }, "ip_address": { "type": "string", "maxLength": 255, "format": "ip-address", "description": "IP address of the customer's device. Can be used for security checks, geolocation, and fraud prevention" }, "device_type": { "type": "string", "description": "Browser engine that can be used for rendering web pages. Example: `WebKit`" }, "device_id": { "type": "string", "description": "Identifier of the customer's device" }, "datetime": { "type": "string", "format": "dateTime", "description": "Date and time when the payment form was opened by the customer in the YYYY-MM-DD hh-mm-ss format. Useful for tracking customer activity and timing of payment initiation. Example: `2022-01-01 15:15:15`" }, "screen_res": { "type": "string", "description": "Screen resolution of the customer's device, in pixels, with an `x` character as a delimiter. Example: `360x640`" }, "session_id": { "type": "string", "description": "Identifier of the session cookie used by the customer" }, "language": { "type": "string", "description": "Customer’s language and country settings. May be used to personalise customer interface, notifications, and messages. The value is provided according to ISO 639-1 (language) and ISO 3166-1 alpha-2 (country) standards. Example: `en_US`" }, "zip": { "type": "string", "maxLength": 10, "description": "Postal or zip code in the customer's address. Example: `75001`" }, "address": { "type": "string", "description": "Name of the street and the house number (including any additional parts of the address such as building indicators and apartment numbers) in the address of the customer. Example: `Via Dietro Duomo 36`" }, "district": { "type": "string", "maxLength": 255, "description": "District of the customer's address" }, "street": { "type": "string", "maxLength": 255, "description": "Name of the street in the customer's address. Example: `Breadmarket Street`" }, "building": { "type": "string", "maxLength": 255, "description": "Building number in the customer’s address. Example: `4`" }, "account_id": { "type": "string", "description": "Identifier of the customer's account in the external payment system" }, "gender": { "type": "string", "enum": [ "male", "female" ], "description": "Identifier of the customer's gender. Possible values: male or female" }, "qq_account_number": { "type": "string", "description": "Customer login in QQ social network" }, "ssn": { "type": "integer", "maxLength": 4, "description": "The last 4 digits of the customer's US social security number" }, "device_fingerprint": { "type": "string", "description": "Identifier generated based on a device's characteristics such as browser type, screen resolution, operating system, fonts, and others" }, "identify": { "type": "object", "description": "Object that contains customer identification document details", "properties": { "doc_number": { "type": "string", "maxLength": 255, "description": "Identifier of the document serving as a proof of identity for the customer. Example: `65432334567`" }, "doc_type": { "type": "string", "maxLength": 255, "description": "Type of identification document" }, "doc_issue_date": { "type": "string", "maxLength": 255, "description": "Date when the identification document was issued. Used for identity verification. Example: `20.12.2012`" }, "doc_issue_by": { "type": "string", "maxLength": 255, "description": "Name of the authority that issued the identification document. Can be used for identity verification. Example: `12346`" }, "doc_issue_country": { "type": "string", "maxLength": 255, "description": "Name of the country where the identification document was issued. Can be used for identity verification" } } }, "billing": { "type": "object", "description": "Object contains customer billing address details", "properties": { "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Customer's country code in the ISO 3166-1 alpha-2 format. Example: `GB`" }, "region": { "type": "string", "description": "Region or state of the customer's billing address" }, "region_code": { "type": "string", "pattern": "^[0-9A-Z]{1,3}$", "description": "The region or state code of the customer's billing address in ISO 3166-2 format" }, "city": { "type": "string", "maxLength": 256, "description": "Name of the place of residence (e.g., town, city, or other settlement type) in the customer's billing address. Example: `London`" }, "address": { "type": "string", "maxLength": 512, "description": "Name of the street and the house number (including any additional parts of the address such as building indicators and apartment numbers) in the customer's billing address. Example: `Via Dietro Duomo 36`" }, "postal": { "type": "string", "maxLength": 16, "description": "Postal code in the customer's billing address.Example: `BR1 1AA`" }, "canadian_province": { "type": "string", "enum": [ "ON", "BC", "AB", "MB", "SK", "QC", "NS", "NB", "NF", "PE", "NT", "NU", "YT" ], "description": "Abbreviation of Canadian province" } } }, "citizenship": { "type": "string", "minLength": 1, "description": "Сode of the sender's country of citizenship in ISO 3166-1 alpha-2" }, "accept_header": { "type": "string", "minLength": 1, "description": "Value of the HTTP Accept request header as received from the customer's browser" }, "color_depth": { "type": "integer", "description": "Colour depth of the screen as supported by the customer's browser, bits per pixel" }, "java_enabled": { "type": "boolean", "description": "Indicator specifying whether the customer's browser supports Java" }, "js_enabled": { "type": "boolean", "description": "Indicator specifying whether the customer's browser supports JavaScript" }, "timezone_offset": { "type": "string", "minLength": 1, "description": "Difference between the time in UTC (Coordinated Universal Time) and the local time of the browser, specified in minutes. Example: `-110`" }, "timezone_name": { "type": "string", "description": "Name of the time zone the customer's browser is set to. Example: `Europe/London`" }, "address_match": { "type": "boolean", "description": "Indicator specifying whether the customer's billing address matches the address specified in the shipping object. Possible values: `true`—addresses match, `false`—addresses do not match" }, "account": { "$ref": "#/components/schemas/AccountInfoAtMerchant" }, "shipping": { "$ref": "#/components/schemas/ShippingInfo" }, "mpi_result": { "$ref": "#/components/schemas/MpiResult" }, "accept_language_header": { "type": "string", "minLength": 1, "description": "Indicates the preferred language(s) of the customer's browser, derived from the Accept-Language HTTP header, for example `en-GB,en;q=0.8,fr;q=0.3`" } }, "description": "Object that contains customer details without ip_address. Use CustomerInfo instead of this" }, "CustomerInfoBnplSale": { "description": "Object that contains customer details", "allOf": [ { "$ref": "#/components/schemas/CustomerInfoBase" }, { "type": "object", "properties": {}, "required": [ "id", "ip_address" ] } ] }, "CustomerInfoCard": { "type": "object", "description": "Object that contains customer details", "allOf": [ { "$ref": "#/components/schemas/CustomerInfo" }, { "type": "object", "properties": { "card_product_type": { "description": "Card product type: business or individual", "type": "string", "enum": [ "Business Card", "Individual Card" ] } }, "required": [ "id" ] } ] }, "CustomerInfoInvoice": { "required": [ "id" ], "type": "object", "properties": { "id": { "type": "string", "maxLength": 255, "description": "Customer identifier unique within the project" }, "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Customer's country code in the ISO 3166-1 alpha-2 format. Example: `GB`" }, "city": { "type": "string", "maxLength": 256, "description": "Customer's address city name" }, "state": { "type": "string", "maxLength": 256, "description": "State" }, "phone": { "type": "string", "pattern": "^[0-9]{4,24}$", "description": "Customer's phone number, can be 4 to 24 digits long" }, "day_of_birth": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Customer's date of birth. This parameter is specified in DD-MM-YYYY format. Example: `12-12-1990`" }, "birthplace": { "type": "string", "maxLength": 255, "description": "Customer's place of birth" }, "first_name": { "type": "string", "maxLength": 255, "description": "Customer first name" }, "middle_name": { "type": "string", "maxLength": 255, "description": "Customer's patronymic" }, "last_name": { "type": "string", "maxLength": 255, "description": "Customer last name" }, "email": { "type": "string", "maxLength": 255, "format": "email", "description": "Customer email" }, "language": { "type": "string", "description": "Customer’s language and country settings. May be used to personalise customer interface, notifications, and messages. The value is provided according to ISO 639-1 (language) and ISO 3166-1 alpha-2 (country) standards. Example: `en_US`" }, "address": { "type": "string", "description": "Customer’saddress" }, "ssn": { "type": "integer", "maxLength": 4, "description": "The last 4 digits of the social security number of US." }, "billing": { "type": "object", "description": "Object contains billing address fields", "properties": { "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Customer's country code in the ISO 3166-1 alpha-2 format. Example: `GB`" }, "region": { "type": "string", "description": "The region or state of the customer's billing address" }, "city": { "type": "string", "maxLength": 256, "description": "City of the billing customer address" }, "address": { "type": "string", "maxLength": 512, "description": "Street account address of the customer" }, "postal": { "type": "string", "maxLength": 16, "description": "Postal code of the billing address of the customer" } } }, "accept_language_header": { "type": "string", "minLength": 1, "description": "Indicates the preferred language(s) of the customer's browser, derived from the Accept-Language HTTP header, for example `en-GB,en;q=0.8,fr;q=0.3`" }, "account_id": { "type": "string", "description": "Customer identifier in external payment system that is used for payment performing" } }, "description": "Object that contains information about the customer" }, "CustomerInfoNameValidation": { "description": "Object that contains customer details for name validation", "allOf": [ { "$ref": "#/components/schemas/CustomerInfo" }, { "type": "object", "properties": { "name_validation": { "type": "boolean", "description": "Parameter that indicates name validation is required for the request" } } } ] }, "CustomerInfoPayout": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfo" }, { "type": "object", "properties": { "id": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Customer identifier unique within the project" } }, "required": [ "id" ] } ] }, "CustomerInfoWalletRecurring": { "description": "Object that contains customer details for recurring payments performing by using e-wallets", "allOf": [ { "$ref": "#/components/schemas/CustomerInfo" }, { "type": "object", "required": [ "id" ] } ] }, "CustomerInfoWithId": { "description": "Object that contains customer details with mandatory identifier", "allOf": [ { "$ref": "#/components/schemas/CustomerInfo" }, { "type": "object", "required": [ "id" ] } ] }, "CryptoPayment": { "type": "object", "properties": { "cryptocurrency_type": { "type": "string", "enum": [ "cbdc", "stablecoins_fiat_backed", "native_tokens", "other" ], "description": "Indicator that specifies the type of the cryptocurrency, required for Mastercard and Visa payments involving cryptocurrencies" } } }, "Descriptor": { "type": "object", "properties": { "descriptor": { "type": "string", "maxLength": 255, "description": "also known as billing descriptor, which is the text identifying the merchant and providing additional information about the payment (for example, the customer identifier, phone number, location information, etc.). In case of card payments, the merchant descriptor is sent to the issuing bank and can be shown on the customer’s bank statement. It can also be utilised otherwise as per specifics of various payment methods." } } }, "ErrorItem": { "type": "object", "properties": { "code": { "type": "integer", "description": "Error code intended to represent the result of the operation processing. Example: `3287`" }, "message": { "type": "string", "description": "Message intended to provide additional details clarifying the cause of the error. Example: `The payment currency is required`" }, "field": { "type": "string", "description": "Name of the parameter that was erroneously specified (if such parameter is identified)" }, "constraint": { "type": "string", "description": "Information about the error. This information can be used to clarify the failure. Example: `required`" } }, "description": "Object that contains single error information" }, "ErrorItems": { "type": "object", "properties": { "errors": { "type": "array", "description": "Array that contains information of one or more error messages", "items": { "$ref": "#/components/schemas/ErrorItem" } } }, "description": "Object that contains information of one or more error messages" }, "ErrorResponse": { "required": [ "status" ], "type": "object", "properties": { "status": { "type": "string", "description": "Status of receiving of the request" }, "code": { "type": "string", "description": "Error code" }, "message": { "type": "string", "description": "Message that clarifies the cause of the error" } }, "description": "Object that contains information about request registration or processing error. Detailed information about the error see in the message parameter of the response" }, "ETokenInfoLight": { "required": [ "token" ], "type": "object", "properties": { "token": { "type": "string", "description": "Token from payment system" } }, "description": "Information about token from payments system" }, "GateSuccessResponse": { "required": [ "payment_id", "project_id", "request_id", "status" ], "type": "object", "properties": { "status": { "type": "string", "maxLength": 255, "description": "Status indicating the result of the request acceptance" }, "request_id": { "type": "string", "maxLength": 100, "description": "Identifier of the request specified by the payment platform" }, "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`" }, "payment_id": { "type": "string", "maxLength": 255, "description": "Identifier of the payment that uniquely identifies a payment within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return. Example: `payment_443`" } }, "description": "Object that contains information about request acceptance or execution in the payment platform" }, "GeneralInfo": { "type": "object", "description": "Object that contains general request details", "required": [ "project_id", "payment_id", "signature" ], "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "payment_id": { "type": "string", "minLength": 1, "maxLength": 255, "strict": true, "description": "Identifier of the payment that uniquely identifies a payment within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return. Example: `payment_443`" }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" }, "merchant_callback_url": { "type": "string", "minLength": 1, "maxLength": 255, "description": "URL for handling request callbacks. This parameter should be passed when callbacks for a request need to be sent to an address that is different from that specified by default (for information about callbacks and how to use them, see [Handling callbacks](https://developers.ecommpay.com/en/en_platform_callbacks.html)). Example: `https://cosmoshop.earth/specialorder`" } } }, "GeneralInfoInvoice": { "required": [ "payment_id", "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "payment_id": { "type": "string", "minLength": 1, "maxLength": 255, "strict": true, "description": "Identifier of the payment that uniquely identifies a payment within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return. Example: `payment_443`" }, "merchant_callback_url": { "type": "string", "minLength": 1, "maxLength": 255, "description": "URL for handling request callbacks. This parameter should be passed when callbacks for a request need to be sent to an address that is different from that specified by default (for information about callbacks and how to use them, see [Handling callbacks](https://developers.ecommpay.com/en/en_platform_callbacks.html)). Example: `https://cosmoshop.earth/specialorder`" }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "description": "Object that contains parameters for generating and submitting a payment link purchase to the payment platform" }, "GeneralInfoClarification": { "type": "object", "description": "Object that contains general request details", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "payment_id": { "type": "string", "minLength": 1, "maxLength": 255, "strict": true, "description": "Identifier of the payment that uniquely identifies a payment within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return. Example: `payment_443`" }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "required": [ "project_id", "payment_id", "signature" ] }, "GeneralInfo3DS": { "type": "object", "description": "Object that contains general request details", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "payment_id": { "type": "string", "minLength": 1, "maxLength": 255, "strict": true, "description": "Identifier of the payment that uniquely identifies a payment within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return. Example: `payment_443`" }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "required": [ "project_id", "payment_id", "signature" ] }, "GiftCardInfo": { "type": "object", "properties": { "amount": { "type": "integer", "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "maxLength": 3, "description": "Currency code in ISO 4217 alpha-3 format" }, "count": { "type": "integer", "maximum": 99, "description": "Number of gift cards" } }, "description": "Object that contains information about gift card" }, "GooglePayETokenInfoLight": { "required": [ "token" ], "type": "object", "properties": { "token": { "type": "string", "description": "Token from the Google Pay service" }, "google_gateway_type": { "type": "string", "description": "GooglePay gateway type. Possible values: `gateway`—the payment data is processed by Ecommpay's acquiring system, `merchant`—the payment data is processed through a third-party payment system" }, "google_tokenization_type": { "type": "string", "description": "GooglePay tokenisation type. Possible values: `DIRECT`—decryption of the Google Pay response on third-party servers, `PAYMENT_GATEWAY`—decryption of the Google Pay response on the Ecommpay side as the payment gateway" }, "google_gateway_id": { "type": "string", "description": "Identifier of the gateway. This parameter is assigned by Google Pay" }, "google_merchant_id": { "type": "string", "description": "Identifier of the merchant. This parameter is assigned by Google Pay" }, "google_gateway": { "type": "string", "description": "Payment gateway in Google Pay, for example `ecommpay` for Ecommpay" }, "google_transaction_id": { "type": "string", "description": "Identifier of the Google Pay payment" } }, "description": "Information about token from payments system" }, "Installment": { "type": "object", "properties": { "ext_plan_id": { "type": "string", "description": "Installment plan ID assigned by VIS" }, "count": { "type": "integer", "description": "Number of installment periods" }, "frequency": { "type": "string", "enum": [ "A", "B", "C", "M", "Q", "S", "T", "W", "2" ], "description": "Payment frequency" }, "terms_and_conditions": { "type": "object", "description": "Terms and conditions of the contract", "properties": { "language": { "type": "string", "description": "Customer’s language and country settings. May be used to personalise customer interface, notifications, and messages. The value is provided according to ISO 639-1 (language) and ISO 3166-1 alpha-2 (country) standards. Example: `en_US`" }, "version": { "type": "number", "description": "Version" } } } } }, "MerchantAuthGeneralInfo": { "required": [ "payment_id", "project_id", "signature", "type" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "payment_id": { "type": "string", "minLength": 1, "maxLength": 255, "strict": true, "description": "Identifier of the payment that uniquely identifies a payment within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return. Example: `payment_443`" }, "type": { "type": "string", "enum": [ "start", "finish" ], "description": "Type of merchant auth request" }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "description": "Object that contains required details of the merchant auth request (customer authentication by the payment system on merchant's request)" }, "MerchantInfo": { "type": "object", "properties": { "descriptor": { "type": "string", "pattern": "^[^!@&~№{}|<>\\[\\]Ёё]*$", "maxLength": 255, "description": "also known as billing descriptor, which is the text identifying the merchant and providing additional information about the payment (for example, the customer identifier, phone number, location information, etc.). In case of card payments, the merchant descriptor is sent to the issuing bank and is shown on the customer’s bank statement. It can also be utilised otherwise as per specifics of various payment methods." }, "data": { "type": "string", "minLength": 1, "description": "Information about the payment provided by the merchant. Can include details about the purchased items or services (number, description, SKU, etc.) or any other relevant data. This information is not sent to the payment provider or other third parties and is used at the merchant’s discretion" } }, "description": "Object that contains additional information provided by the merchant" }, "MotoInfo": { "type": "object", "description": "Object that contains payment details including MO/TO type", "properties": { "moto_type": { "type": "integer", "default": 0, "enum": [ 0, 1, 2 ], "description": "Type of a Mail Order/telephone Order purchase determined by the way the cardholder provides the card details (phone, mail, fax, or email). Possible values: `0`—not a MO/TO payment, `1`—Mail Order payment, `2`—Telephone Order payment" } } }, "MpiResult": { "type": "object", "properties": { "acs_operation_id": { "type": "string", "pattern": "^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$", "description": "Operation identifier in ACS" }, "authentication_flow": { "type": "string", "pattern": "^0[1-2]$", "description": "The indicator of the flow that was used for the customer 3-D Secure 2 authentication within the previous operation" }, "authentication_timestamp": { "type": "string", "pattern": "^\\d{12}$", "description": "Date and time of the previous successful customer authentication as returned in the `mpi_timestamp` parameter of the callback with payment processing result. Format: A numeric string containing exactly 12 digits with no spaces, letters, or special characters" } }, "description": "An object that contains information about previous mpi result" }, "OperationInfo": { "type": "object", "properties": { "id": { "type": "integer", "description": "Unique identifier of the operation in the payment platform" }, "type": { "type": "string", "description": "Operation type" }, "status": { "type": "string", "description": "Operation status" }, "date": { "type": "string", "description": "Date and time when the operation status was most recently updated in the payment platform, in ISO 8601 format" }, "created_date": { "type": "string", "description": "Date and time when the operation was created in the payment platform in the format according to the ISO 8601 standart" }, "sum_initial": { "$ref": "#/components/schemas/Sum" }, "sum_converted": { "$ref": "#/components/schemas/Sum" }, "request_id": { "type": "string", "description": "Identifier of the request specified by the payment platform" }, "provider": { "$ref": "#/components/schemas/ProviderResultInfo" }, "code": { "type": "string", "description": "Operation processing result code" }, "message": { "type": "string", "description": "Operation processing result message" }, "eci": { "type": "string", "description": "Electronic Commerce Indicator, used for communicating whether the authentication was initiated and what was its outcome as well as whether the issuer or the merchant is responsible for approving payment processing and will take potential financial responsibility if a chargeback occurs. For more information, see [Electronic Commerce Indicators](https://developers.ecommpay.com/en/en_ECI_codes.html)" }, "operation_fee": { "type": "object", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Operation fee amount in minor currency units. Example: `31`" }, "currency": { "type": "string", "pattern": "^[:_A-Z0-9]{3,27}$", "description": "Currency code in the ISO-4217 alpha-3 format. Example: `USD`" } } } }, "description": "Object that contains operation details" }, "PaymentBanksInfo": { "required": [ "amount", "currency" ], "type": "object", "properties": { "amount": { "type": "integer", "minimum": 0, "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency code in the ISO 4217 alpha-3 format" }, "customer_amount": { "type": "integer", "minimum": 0, "maximum": 10000000000000, "description": "Payment amount converted into the currency selected by the customer. This parameter is specified in minor units of currency" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description or comment for additional data analisys by using Dashboard" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" }, "best_before": { "type": "string", "format": "date-time", "description": "Payment expiration date in the date-time format according to the ISO 8601 standart" }, "challenge_indicator": { "type": "string", "pattern": "^0[1-9]$", "description": "Indicates whether the challenge flow is preferred. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "challenge_window": { "type": "string", "pattern": "^0[1-5]$", "description": "The dimensions of a window in which the authentication page opens. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "reorder": { "type": "string", "pattern": "^0[1-2]$", "description": "Indicates whether the customer is buying the merchandise or the service for the first time or it is a repeat purchase. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_purchase": { "type": "string", "pattern": "^0[1-2]$", "description": "Parameter specifying whether the current purchase is pre-ordered. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date when the preordered merchandise or service will be available in the DD-MM-YYYY format" }, "gift_card": { "$ref": "#/components/schemas/GiftCardInfo" }, "local_conversion_currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Conversion currency code, provided in ISO 4217 alpha-3 format" }, "details": { "type": "object", "description": "Object that contains customer identification document details", "properties": { "document_number": { "type": "string", "description": "Number of the identification document used for verification" }, "document_date": { "type": "string", "description": " Date when the relevant contract or document was concluded" } } }, "device_channel": { "type": "string", "pattern": "^0[1-3]$", "description": "Indicator that specifies the type of the interface through which the web service initiates the 3-D Secure authentication. By default, it is set to `02` (Browser-based). In specific cases that must be agreed upon and approved, the value of this parameter can be `01` (App-based) and `03` (3DS Requestor Initiated). If `01` or `03` value is passed when it was not initially agreed upon, the payment may get declined" } }, "description": "Object that contains payment details" }, "PaymentInfo": { "required": [ "amount", "currency" ], "type": "object", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency code in ISO-4217 alpha-3 format. Example: `USD`" }, "customer_amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Payment amount converted into the currency selected by the customer. This parameter is specified in minor units of currency" }, "description": { "type": "string", "maxLength": 255, "description": "Description of the payment intended to provide additional context or comments" }, "end_to_end_id": { "type": "string", "maxLength": 35, "description": "Identifier provided by the SEPA payment initiator. This parameter is intended to be routed through the entire SEPA payment process" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" }, "best_before": { "type": "string", "format": "date-time", "description": "Payment link expiry date and time, in the ISO 8601 format" }, "challenge_indicator": { "type": "string", "pattern": "^0[1-9]$", "description": "Indicates whether the challenge flow is preferred. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "challenge_window": { "type": "string", "pattern": "^0[1-5]$", "description": "Dimensions of a window in which the authentication page opens. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "reorder": { "type": "string", "pattern": "^0[1-2]$", "description": "Indicates whether the customer is buying the merchandise or the service for the first time or it is a repeated purchase. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_purchase": { "type": "string", "pattern": "^0[1-2]$", "description": "Parameter specifying whether the current purchase is pre-ordered. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date when the preordered merchandise or service will be available in the DD-MM-YYYY format" }, "gift_card": { "$ref": "#/components/schemas/GiftCardInfo" }, "local_conversion_currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment conversion currency code, provided in ISO 4217 alpha-3 format" }, "details": { "type": "object", "description": "Object intended to contain the customer's identification document details", "properties": { "document_number": { "type": "string", "description": "Number of the identification document used for verification" }, "document_date": { "type": "string", "description": "Date when the relevant contract or document was concluded" } } }, "device_channel": { "type": "string", "pattern": "^0[1-3]$", "description": "Indicator that specifies the type of the interface through which the web service initiates the 3-D Secure authentication. By default, it is set to `02` (Browser-based). In specific cases that must be agreed upon and approved, the value of this parameter can be `01` (App-based) and `03` (3DS Requestor Initiated). If `01` or `03` value is passed when it was not initially agreed upon, the payment may get declined" }, "is_fast": { "type": "boolean", "description": "Indicator specifying whether the payment is processed using a fast payment method" } }, "description": "Object that contains payment details" }, "PaymentInfoDirectDebit": { "required": [ "currency" ], "type": "object", "properties": { "amount": { "type": "integer", "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[:_A-Z0-9]{3,27}$", "description": "Payment currency in the ISO 4217 alpha-3 format" }, "customer_amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Payment amount converted into the currency selected by the customer. This parameter is specified in minor units of currency" }, "description": { "type": "string", "maxLength": 255, "description": "Textual comment or description of the payment, can be used for additional data analysis and reporting in Dashboard" }, "end_to_end_id": { "type": "string", "maxLength": 35, "description": "SEPA identifier (provided by initiating SEPA transaction end-customer), routed through the whole payment process." }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" }, "best_before": { "type": "string", "format": "date-time", "description": "Payment expiration date in the date-time format according to the ISO 8601 standart" }, "challenge_indicator": { "type": "string", "pattern": "^0[1-9]$", "description": "Indicates whether the challenge flow is preferred. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "challenge_window": { "type": "string", "pattern": "^0[1-5]$", "description": "The dimensions of a window in which the authentication page opens. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "reorder": { "type": "string", "pattern": "^0[1-2]$", "description": "Indicates whether the customer is buying the merchandise or the service for the first time or it is a repeat purchase. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_purchase": { "type": "string", "pattern": "^0[1-2]$", "description": "Parameter specifying whether the current purchase is pre-ordered. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date when the preordered merchandise or service will be available in the DD-MM-YYYY format" }, "gift_card": { "$ref": "#/components/schemas/GiftCardInfo" }, "local_conversion_currency": { "type": "string", "pattern": "^[:_A-Z0-9]{3,27}$", "description": "Payment conversion currency code, provided in ISO 4217 alpha-3 format" }, "details": { "type": "object", "description": "Object intended to contain customer identification document details", "properties": { "document_number": { "type": "string", "description": "Number of the identification document that can be used for verification" }, "document_date": { "type": "string", "description": "Date when the relevant contract or document was concluded" } } }, "device_channel": { "type": "string", "pattern": "^0[1-3]$", "description": "Indicator that specifies the type of the interface through which the web service initiates the 3-D Secure authentication. By default, it is set to `02` (Browser-based). In specific cases that must be agreed upon and approved, the value of this parameter can be `01` (App-based) and `03` (3DS Requestor Initiated). If `01` or `03` value is passed when it was not initially agreed upon, the payment may get declined" }, "is_fast": { "type": "boolean", "description": "Indicator intended to show whether the payment is processed using a fast payment method" } } }, "PaymentInfoForCard": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfoWMoTo" }, { "$ref": "#/components/schemas/CryptoPayment" }, { "type": "object", "description": "Object that contains payment details for card", "properties": { "debt_account": { "type": "string", "maxLength": 10, "description": "The number of the account designated to receive funds as part of the debt settlement purchases. Example: `an9876170i`" }, "allow_partial_approval": { "type": "boolean", "description": "Parameter that indicates whether the merchant accepts partial approval for this purchase" } } } ] }, "PaymentInfoInvoice": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfoInvoiceByToken" }, { "type": "object", "properties": { "force_method": { "type": "string", "maxLength": 255, "description": "Identifier of the payment method intended to be opened by default, without the option for the customer to select a different payment method. For complete list of payment methods codes, see [Payment method codes](https://developers.ecommpay.com/en/en_pm_codes.html)" } } } ] }, "PaymentInfoInvoiceByToken": { "required": [ "amount", "best_before", "currency" ], "type": "object", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency code in ISO 4217 alpha-3 format" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" }, "best_before": { "type": "string", "format": "date-time", "description": "Date and time of payment expiration. Keep in mind that the validity period of the payment link cannot exceed 30 days" }, "moto_type": { "type": "integer", "default": 0, "enum": [ 0, 1, 2 ], "description": "Type of a Mail Order/Telephone Order purchase determined by the way the cardholder provides the card details (phone, mail, fax, or email). Possible values: `0`—not a MO/TO payment, `1`—Mail Order payment, `2`—Telephone Order payment" } }, "description": "Object which contains payment information for invoice by token" }, "PaymentInfoPayoutOnlineBanking": { "required": [ "amount", "currency" ], "type": "object", "properties": { "amount": { "type": "integer", "minimum": 0, "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency code in ISO 4217 alpha-3 format" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" } }, "description": "Object which contains payment information" }, "PaymentInfoRecurring": { "required": [ "amount", "currency" ], "type": "object", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency code in the ISO 4217 alpha-3 format. Example: `USD`" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description or comment for additional data analisys by using Dashboard" }, "extra_param": { "type": "string", "maxLength": 255, "description": "Parameter for passing additional settings for customise the payment processing flow" }, "challenge_indicator": { "type": "string", "pattern": "^0[1-9]$", "description": "Indicates whether the challenge flow is preferred. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "challenge_window": { "type": "string", "pattern": "^0[1-5]$", "description": "The dimensions of a window in which the authentication page opens. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "reorder": { "type": "string", "pattern": "^0[1-2]$", "description": "Indicates whether the customer is buying the merchandise or the service for the first time or it is a repeated purchase. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_purchase": { "type": "string", "pattern": "^0[1-2]$", "description": "Parameter specifying whether the current purchase is pre-ordered. For more information, see [3‑D Secure authentication](https://developers.ecommpay.com/en/en_gate_payment_3ds.html). Example: `01`" }, "preorder_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date when the preordered merchandise or service will be available in the DD-MM-YYYY format" }, "gift_card": { "$ref": "#/components/schemas/GiftCardInfo" }, "local_conversion_currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency code in the ISO 4217 alpha-3 format" }, "details": { "type": "object", "description": "Object that contains customer identification document details", "properties": { "document_number": { "type": "string", "description": "Number of the identification document used for verification" }, "document_date": { "type": "string", "description": "Date when the relevant contract or document was concluded" } } }, "device_channel": { "type": "string", "pattern": "^0[1-3]$", "description": "Indicator that specifies the type of the interface through which the web service initiates the 3-D Secure authentication. By default, it is set to `02` (Browser-based). In specific cases that must be agreed upon and approved, the value of this parameter can be `01` (App-based) and `03` (3DS Requestor Initiated). If `01` or `03` value is passed when it was not initially agreed upon, the payment may get declined" } }, "description": "Object that contains payment details" }, "PaymentInfoWMoTo": { "allOf": [ { "$ref": "#/components/schemas/PaymentInfo" }, { "type": "object", "description": "Object that contains payment details including MO/TO type", "properties": { "moto_type": { "type": "integer", "default": 0, "enum": [ 0, 1, 2 ], "description": "Type of a Mail Order/telephone Order purchase determined by the way the cardholder provides the card details (phone, mail, fax, or email). Possible values: `0`—not a MO/TO payment, `1`—Mail Order payment, `2`—Telephone Order payment" } } } ] }, "PaymentResultInfo": { "type": "object", "properties": { "id": { "type": "string", "description": "payment id" }, "payment_system_id": { "type": "integer", "description": "Identifier of the payment provider in the payment platform" }, "method": { "type": "string" }, "endpoint_id": { "type": "integer" }, "result_code": { "type": "string" }, "result_message": { "type": "string" }, "date": { "type": "string", "description": "Date of the payment processing" } }, "description": "information about external payment system used" }, "PaymentStatusResponse": { "required": [ "operations", "payment", "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`" }, "payment": { "type": "object", "description": "Object that contains payment details", "properties": { "id": { "type": "string", "description": "Unique identification of the payment in the payment platform" }, "type": { "type": "string", "description": "Payment type" }, "status": { "type": "string", "description": "Payment status", "minLength": 1 }, "sum": { "$ref": "#/components/schemas/Sum" }, "date": { "type": "string", "description": "Date and time when the operation status was most recently updated in the payment platform, in ISO 8601 format" }, "description": { "type": "string", "description": "Description of the payment passed in the initial request" }, "method": { "type": "string", "description": "Payment method that used to perform the payment" } }, "required": [ "status" ] }, "operations": { "type": "array", "description": "List of operations performed within the payment", "items": { "$ref": "#/components/schemas/OperationInfo" } }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "recurring": { "type": "object", "description": "Object that contains recurring registration details of the payment. Details is submitted if the initial request for payment is passed with `recurring_registration=1` and the payment is successfully processed", "properties": { "id": { "type": "integer", "description": "Identifier of the created credential-on-file (COF) purchase. Can be used to perform and manage COF purchases" }, "currency": { "type": "string", "description": "Payment currency code in ISO 4217 alpha-3 format" }, "valid_thru": { "type": "string", "description": "Expiration date of the record about a series of funds debiting. Example: `2025-03-30 16:15:00`" } } }, "account": { "type": "object", "description": "Object that contains customer's payment instrument (card, bank account, wallet, etc.) details", "properties": { "number": { "type": "string", "description": "Customer's account number. Example: `21312`", "minLength": 1 }, "type": { "type": "string", "description": "Payment instrument type" }, "card_holder": { "type": "string", "description": "Name of the cardholder as specified on the payment card" }, "token": { "type": "string", "description": "Customer's card token identifier" }, "token_created_at": { "type": "string", "description": "Date and time of the token generation, specified in the ISO 8601 format with the UTC offset. Example: `2024-07-21T03:31:24+0000" } }, "required": [ "number" ] }, "acs": { "type": "object", "description": "Object that contains 3-D Secure data in case the card requires 3-D Secure authentication", "properties": { "pa_req": { "type": "string", "description": "Payer Authentication Request message received during the 3‑D Secure authentication", "minLength": 1 }, "md": { "type": "string", "description": "Merchant data received from a global card network during the 3‑D Secure authentication", "minLength": 1 }, "acs_url": { "type": "string", "description": "URL of the page to which the customer is redirected for the 3‑D Secure authentication (Access Control Server page)", "minLength": 1 } }, "required": [ "pa_req", "md", "acs_url" ] }, "errors": { "type": "array", "description": "Array of error messages", "items": { "$ref": "#/components/schemas/ErrorItem" } }, "signature": { "type": "string", "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)." } }, "description": "Object that contains the payment details passed to the request for payment status clarifying" }, "ProviderResultInfo": { "type": "object", "properties": { "id": { "type": "integer", "description": "Payment provider identifier in the payment platform. Example: `123`" }, "payment_id": { "type": "string", "description": "Identifier of the payment that uniquely identifies a payment within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return. Example: `payment_443`" }, "auth_code": { "type": "string", "description": "Authorisation code received from a provider or a payment system. Example: `591748`" }, "endpoint_id": { "type": "integer", "description": "Identifier of the payment gateway provided by the payment provider or system in CRC32 format. Example: `2`" }, "result_code": { "type": "string", "description": "Result code provided by the payment provider or the payment system intended to indicate the result of the operation. Example: `00`" }, "result_message": { "type": "string", "description": "Message with the result of operation. The parameter is provided by the payment provider or the payment system and offers additional details regarding the operation status and any related information. Example: `Success`" }, "date": { "type": "string", "description": "Date and time when processing of the payment was completed on a provider or a payment system side. Example: `2022-02-22T19:52:14+0000`" } }, "description": "Object containing information from the payment provider regarding the result of the operation" }, "ReceiptData": { "type": "object", "properties": { "positions": { "type": "array", "items": { "$ref": "#/components/schemas/ReceiptPositionData" }, "minItems": 1, "maxItems": 300 }, "total_tax_amount": { "type": "integer", "description": "Tax amount for a line item, specified in minor units of currency. Example: `1800``" }, "common_tax": { "type": "number", "multipleOf": 0.01, "description": "Applicable tax rate, specified if it is the same for all line items in the order. Example: `18`" } }, "description": "Object that contains the list of line items to be sent to the customer in the receipt once the payment is processed" }, "ReceiptPositionData": { "required": [ "amount" ], "type": "object", "properties": { "quantity": { "type": "number", "multipleOf": 0.000001, "description": "Quantity of the goods and services. Example: `3`" }, "amount": { "type": "integer", "description": "Total cost for a particular line item. Calculated by multiplying the quantity of that item by its unit price. Specified in minor units of currency. Example: `10000`" }, "tax": { "type": "number", "multipleOf": 0.01, "description": "Tax percentage applicable to the product or service. Example: `18`" }, "tax_amount": { "type": "integer", "description": "Tax amount for a line item, specified in minor units of currency. Example: `1800`" }, "description": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Description of a specific product or service being purchased. Example: `Photo frame`" } }, "description": "Object that contains information about each line item in the purchase" }, "RecipientForCard": { "anyOf": [ { "required": [ "wallet_owner", "wallet_id" ], "type": "object", "description": "Object that contains the data of the payment recipient", "properties": { "wallet_owner": { "type": "string", "maxLength": 255, "pattern": "^[a-zA-Z0-9\\s\\-.']+$", "description": "First and last name of the recipient who owns the digital wallet to which the funds will be credited. Example: `Fran Petrarca`" }, "wallet_id": { "type": "string", "maxLength": 64, "pattern": "^[^!@&~№{}|<>\\[\\]]*$", "description": "Identifier of the digital wallet. Specified as is, without masked characters, spaces, or other separators. Example:`WID20071304`" }, "card_holder": { "type": "string", "maxLength": 255, "pattern": "^[a-zA-Z0-9\\s\\-.']+$", "description": "Name of the recipient (as specified on the card)" }, "country": { "maxLength": 2, "pattern": "^[A-Z]{2}$", "type": "string", "description": "Recipient's country code in the ISO 3166-1 alpha-2 format. Example: `GB`" }, "address": { "maxLength": 99, "type": "string", "description": "Recipient address" }, "city": { "maxLength": 25, "type": "string", "description": "Name of recipient's address city" }, "state_code": { "maxLength": 3, "pattern": "^[A-Z]+$", "type": "string", "description": "State code of recipient" }, "day_of_birth": { "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "type": "string", "description": "Recipient's date of birth. This parameter is specified in DD-MM-YYYY format. Example: `12-12-1990`" } } }, { "required": [ "card_holder", "pan" ], "type": "object", "description": "Object that contains the data of the transfer recipient", "properties": { "card_holder": { "type": "string", "maxLength": 255, "pattern": "^[a-zA-Z0-9\\s\\-.']+$", "description": "Name of the cardholder as specified on the payment card" }, "pan": { "type": "string", "pattern": "^[0-9]{15,19}$", "description": "Number of the payment card used for payment. Specified as is, without masked characters, spaces, or other separators. Example:`4314220000000056`" }, "country": { "maxLength": 2, "pattern": "^[A-Z]{2}$", "type": "string", "description": "Recipient's country code in the ISO 3166-1 alpha-2 format. Example: `GB`" }, "address": { "maxLength": 99, "type": "string", "description": "Recipient address" }, "city": { "maxLength": 25, "type": "string", "description": "Namr of recipient's address city" }, "state_code": { "maxLength": 3, "pattern": "^[A-Z]+$", "type": "string", "description": "State code of recipient" }, "day_of_birth": { "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "type": "string", "description": "Recipient's date of birth. This parameter is specified in DD-MM-YYYY format. Example: `12-12-1990`" } } } ] }, "RecurringIdInfo": { "required": [ "id" ], "type": "object", "properties": { "id": { "type": "integer", "minimum": 1, "description": "Unique identifier of the recurring payment in the payment platform" } }, "description": "Object that contains Identifier of the created credential-on-file (COF) purchase. Can be used to perform and manage COF purchasesentifier" }, "RecurringInfo": { "type": "object", "properties": { "type": { "type": "string", "pattern": "^[RCU]$", "description": "Payment type" }, "expiry_year": { "type": "integer", "minimum": 2020, "maximum": 9999, "description": "Year of expiration for credential-on-file (COF) payment. Can be used to define the last year when COF payment are allowed. If this parameter is not passed in the request, the payment platform will use the default values (for detailed information, refer to the documentation portal)" }, "expiry_month": { "type": "integer", "minimum": 1, "maximum": 12, "description": "Month of expiration for credential-on-file (COF) payment. Can be used together with `expiry_year` to set the final period of recurring payment validity. If this parameter is not passed in the request, the payment platform will use the default values (for detailed information, refer to the documentation portal)" }, "expiry_day": { "type": "integer", "minimum": 1, "maximum": 31, "description": "Day of expiration for credential-on-file (COF) payment. Can be used together with `expiry_month` and `expiry_year` to specify the exact expiration date. If this parameter is not passed in the request, the payment platform will use the default values (for detailed information, refer to the documentation portal)" }, "interval": { "type": "integer", "minimum": 1, "maximum": 100, "description": "Interval of performing regular purchases. This parameter should be assigned a numeric value from `1` to `100` (for example, each three weeks) and is necessarily used in conjunction with the **period** parameter. May be used to configure payment recurrence frequency" }, "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Amount of payment in minor currency units" }, "period": { "type": "string", "pattern": "^[DWMQY]$", "description": "Frequency interval of recurring debit operations executed within a credential-on-file (COF) payment. Possible values: `D`—Day, `W`—Week, `M`—Month, `Q`—Quarter, `Y`—Year" }, "time": { "type": "string", "pattern": "^([0-1][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]$", "description": "Time of performing subsequent debits (for a regular purchase) in the hh:mm:ss format. The parameter may be used if the **period** parameter is specified in the request" }, "register": { "type": "boolean", "description": "Indicator that defines whether the payment should be registered as credential-on-file. Is assigned to the true value to register credential-on-file payment" }, "scheduled_payment_id": { "type": "string", "maxLength": 255, "description": "Identifier assigned to the payment (as **payment_id**) within which scheduled debits are performed; it must differ from the identifier of the payment made to register a credential-on-file purchase and must be unique within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return Example: `A2323`" }, "start_date": { "type": "string", "maxLength": 19, "pattern": "^([0-3]\\d-){2}[1-2]\\d{3}$", "description": "First automatic payment date and time in DD-MM-YYYY format. Obligatory when `scheduled_payment_id` is set. Applicable only when **recurring.type = R** and **recurring.period** is set. Is used to authorize and perform the next recurring payment. **start_date** can't be less than the response date of the initial *sale/auth* request within which the recurring was registered" } }, "description": "Object that contains recurring payment details and conditions" }, "RecurringInfoSuccess": { "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`" }, "recurring": { "type": "object", "description": "Object that contains information about the credential-on-file (COF) purchase. For more information, see [Credential-on-file (COF) purchases](https://developers.ecommpay.com/en/en_Gate__payments_on_saved_data.html)", "properties": { "id": { "type": "integer", "description": "Identifier of the created credential-on-file (COF) purchase. Can be used to perform and manage COF purchases" }, "type": { "type": "string", "description": "Indicator of the credential-on-file purchase type. Example: `R`" }, "period": { "type": "string", "description": "Frequency interval of recurring debit operations executed within a credential-on-file (COF) payment. Possible values: `D`—Day, `W`—Week, `M`—Month, `Q`—Quarter, `Y`—Year" }, "period_interval": { "type": "string", "description": "Multiplicator to increase debiting period, for example to run debiting every third week, `period` should be set to `W` and `interval` should be set to `3`. Possible values: from `1` to `100`. Example: `3`" }, "start_date": { "type": "string", "description": "Date to perform the first debit in the yyyy-mm-dd format." }, "start_time": { "type": "string", "description": "Time of subsequent debiting in the HH:mm format" }, "amount": { "type": "string", "description": "Debit amount in minor units of currency" }, "currency": { "type": "string", "description": "Currency code in ISO-4217 alpha-3 format" }, "payment_method": { "type": "string", "description": "Code of the payment method that was used to make the payment to register a COF purchase (according to [the reference table](https://developers.ecommpay.com/en/en_pm_codes.html), with relevant codes listed in the Gate, Dashboard column)" }, "last_payment_at": { "type": "string", "description": "The date when the last debit was made. Example: `2025-03-30 16:15:00`" }, "valid_thru": { "type": "string", "description": "Expiration date of the record about a series of funds debiting" }, "status": { "type": "string", "description": "Indicator of the current state of the debiting series record created after a successful COF purchase registration. Example: `active`" }, "description": { "type": "string", "description": "Description of the credential-on-file purchase", "maxLength": 255 }, "schedule_date": { "type": "object", "properties": { "next": { "type": "string", "description": "Next scheduled payment date in the YYYY-MM-DD hh-mm-ss format" }, "last": { "type": "string", "description": "Last scheduled payment date in the YYYY-MM-DD hh-mm-ss format" } } } } }, "retry_info": { "type": "object", "description": "Object that contains information about the credential-on-file purchase retry attempts", "properties": { "trigger_operation_id": { "type": "integer", "description": "Identifier of the debit operation that is being retried. Example: `092384`" }, "next_retry_exists": { "type": "boolean", "description": "Indicator that shows whether the next scheduled attempt is available. Possible values: `true`—specified when the debiting resulted in decline and there is an available retry attempt (the number of attempts and the time allocated for making them are not used up); `false`—in all other cases" }, "next_retry_date": { "type": "string", "description": "Scheduled date and time of the next retry attempt. Example: `2023-05-24T16:58:02+0000`" } } } }, "description": "Object that contains general information about the credential-on-file purchase" }, "RecurringRequiredInfo": { "allOf": [ { "$ref": "#/components/schemas/RecurringInfo" }, { "required": [ "type" ] } ] }, "RecurringUpdateInfo": { "required": [ "id" ], "type": "object", "properties": { "id": { "type": "integer", "minimum": 1, "description": "Identifier of the created credential-on-file (COF) purchase. Can be used to perform and manage COF purchases" }, "expiry_year": { "type": "integer", "minimum": 2020, "maximum": 9999, "description": "Year of expiration for credential-on-file (COF) payment. Can be used to define the last year when COF payment are allowed" }, "expiry_month": { "type": "integer", "minimum": 1, "maximum": 12, "description": "Month of expiration for credential-on-file (COF) payment. Can be used together with expiry_year to set the final period of recurring payment validity" }, "expiry_day": { "type": "integer", "minimum": 1, "maximum": 31, "description": "Day of expiration for credential-on-file (COF) payment. Can be used together with expiry_month and expiry_year to specify the exact expiration date" }, "interval": { "type": "integer", "minimum": 1, "maximum": 100, "description": "Interval of performing regular purchases. This parameter should be assigned a numeric value from `1` to `100` (for example, each three weeks) and is necessarily used in conjunction with the **period** parameter. May be used to configure payment recurrence frequency" }, "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Amount of payment in minor currency units" }, "period": { "type": "string", "pattern": "^[DWMQY]$", "description": "Frequency interval of recurring debit operations executed within a credential-on-file (COF) payment. Possible values: `D`—Day, `W`—Week, `M`—Month, `Q`—Quarter, `Y`—Year" }, "time": { "type": "string", "pattern": "^([0-1][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]$", "description": "Time of performing subsequent debits (for a regular purchase) in hh:mm:ss format. The parameter may be used if the **period** parameter is specified in the request" }, "scheduled_payment_id": { "type": "string", "maxLength": 255, "description": "Identifier assigned to the payment (as **payment_id**) within which scheduled debits are performed; it must differ from the identifier of the payment made to register a credential-on-file purchase and must be unique within the project. This identifier is case-insensitive: identifiers such as `order_314` and `Order_314` are considered identical. The identifier can include any letters, digits, and symbols in UTF-8 encoding, except when certain characters appear at the beginning or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return Example: `A2323`" }, "start_date": { "type": "string", "maxLength": 19, "pattern": "^([0-3]\\d-){2}[1-2]\\d{3}$", "description": "First automatic payment date and time in format **DD-MM-YYYY**. Obligatory when scheduled_payment_id is set. Applicable only when **recurring.type = R** and **recurring.period** is set. Is used to authorize and perform the next recurring payment. **start_date** can't be less than the response date of the initial *sale/auth* request within which the recurring was registered" }, "description": { "type": "string", "description": "Description for recurring", "maxLength": 255 } }, "description": "Object that contains updating recurring payment details" }, "RefundPaymentInfo": { "required": [ "description" ], "type": "object", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Refund amount in minor currency units" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Currency code in ISO-4217 alpha-3 format" }, "description": { "type": "string", "maxLength": 255, "description": "Refund description or comment" }, "merchant_refund_id": { "type": "string", "maxLength": 255, "description": "Identifier of the refund for representing the refund operation within the merchant’s service" } }, "description": "Object that contains refund processing details" }, "ReturnUrl": { "type": "object", "properties": { "success": { "type": "string", "description": "URL for redirecting the customer to the merchant's web service after the payment is completed" }, "decline": { "type": "string", "description": "URL for redirecting the customer to the merchant's web service after the payment is declined" }, "return": { "type": "string", "description": "URL for redirecting the customer to the merchant's web service when the customer decides not to complete the payment" } }, "description": "Object that contains the URLs to which customer is redirected while or after payment performing" }, "SavedAccount": { "required": [ "id", "number" ], "type": "object", "properties": { "id": { "type": "integer", "description": "Identifier of the payment instrument in the payment platform" }, "number": { "type": "string", "description": "Masked number or another identifier of the customer's payment instrument (for example, a payment card, an account, or a digital wallet). Example: `424242***4243`" }, "type": { "type": "string", "description": "Type of the saved payment instrument. Example: `card`" }, "additional": { "type": "object", "description": "Object intended to contain supplementary details related to the payment instrument and customer", "properties": { "country": { "type": "string", "description": "Customer's country code in the ISO 3166-1 alpha-2 format. Example: `GB`" }, "phone": { "type": "string", "description": "Customer's phone number, can be 4 to 24 digits long" }, "email": { "type": "string", "description": "Customer's email address" }, "card": { "type": "object", "description": "Card information", "properties": { "expiry": { "type": "string", "description": "Expiration date of the card intended to indicate the final valid month and year in the MM/YY format. Example: `02/24`" }, "holder": { "type": "string", "description": "Name of the cardholder on the payment card" }, "type": { "type": "string", "description": "Payment card brand that was used in the processing of the payment, for example, Mastercard, Visa, and others" }, "country": { "type": "string", "description": "Customer's country code in the ISO 3166-1 alpha-2 format. Example: `GB`", "pattern": "^[A-Z]{2}$" }, "product_name": { "type": "string", "description": "Name of the card product. Example: `PREPAID`" }, "bank_name": { "type": "string", "description": "Name of the financial institution that issued the card. Example: `CITIGROUP`" } } }, "recurring_enable": { "type": "boolean", "description": "Indicator showing whether credential-on-file purchase is created and active" } } }, "last_deposit_date": { "type": "string", "description": "Date indicating the most recent deposit operation using this payment instrument" }, "last_payout_date": { "type": "string", "description": "Date indicating the most recent payout operation using this payment instrument" }, "last_tokenize_date": { "type": "string", "description": "Date indicating when this payment instrument was most recently tokenized" }, "token": { "type": "string", "description": "Payment card token" }, "operation_type": { "type": "array", "description": "Indicator that specifies the type of the operation during which the payment instrument was saved. Example: `sale`" } }, "description": "Object that contains the customer's saved payment instrument details" }, "SenderInfo": { "type": "object", "properties": { "first_name": { "type": "string", "maxLength": 255, "description": "Sender's first name. Example: `Jane`" }, "middle_name": { "type": "string", "maxLength": 255, "description": "Sender's middle, second, or patronymic name. Example: `Mary`" }, "last_name": { "type": "string", "maxLength": 255, "description": "Sender's last name. Example: `Smith`" }, "day_of_birth": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Sender's date of birth. This parameter is specified in DD-MM-YYYY format. Example: `12-12-1990`" }, "birthplace": { "type": "string", "maxLength": 255, "description": "Name of the sender's birthplace (e.g., town, city, or other settlement type). Example: `London`" }, "phone": { "type": "string", "pattern": "^[0-9]{4,24}$", "description": "Sender's phone number, can be 4 to 24 digits long" }, "residence": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Code of the country in the sender's billing address, specified in ISO 3166-1 alpha-2" }, "citizenship": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Сode of the sender's country of citizenship in ISO 3166-1 alpha-2" }, "person_type": { "type": "string", "description": "Type of the customer as a legal person, for example, a company or an individual, used for compliance" }, "account_number": { "type": "string", "maxLength": 255, "description": "Account number of the sender. Can be used for payment processing and compliance check" }, "payment_purpose": { "type": "string", "maxLength": 255, "description": "Declared purpose of the payment provided for anti-money laundering (AML) compliance checks." }, "source_of_income": { "type": "string", "maxLength": 255, "description": "Declared source of income of the sender used for anti-money laundering (AML) compliance" }, "beneficiary_relationship": { "type": "string", "maxLength": 255, "description": "Relationship between the sender and the recipient such as `employee` or `buyer`" }, "identify": { "type": "object", "description": "Object that contains sender's identification details", "properties": { "doc_number": { "type": "string", "maxLength": 255, "description": "Identity document number" }, "doc_type": { "type": "string", "maxLength": 255, "description": "Type of identity document" }, "doc_issue_date": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date of issue of identity document" }, "doc_issue_by": { "type": "string", "maxLength": 255, "description": "Who issued the identity document" } } }, "billing": { "type": "object", "description": "Object contains billing address fields", "properties": { "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Country code of the sender's billing address in ISO 3166-1 alpha-2 format" }, "city": { "type": "string", "maxLength": 256, "description": "City of the billing sender address" }, "state": { "type": "string", "maxLength": 256, "description": "State of the sender address" }, "address": { "type": "string", "maxLength": 512, "description": "Street account address of the sender" }, "postal": { "type": "string", "maxLength": 16, "description": "Postal code of the billing address of the sender" } } }, "pan": { "type": "string", "maxLength": 32, "description": "Number of the payment card used for payment. Specified as is, without masked characters, spaces, or other separators. Example:`4314220000000056`" }, "wallet_id": { "type": "string", "maxLength": 64, "pattern": "^[^!@&~№{}|<>\\[\\]]*$", "description": "Identifier of the digital wallet. Specified as is, without masked characters, spaces, or other separators. Example:`WID20071304`" }, "address": { "maxLength": 255, "type": "string", "description": "Name of the street and the house number (including any additional parts of the address such as building indicators and apartment numbers) in the address of the payment sender. Example: `Via Certado 18`" }, "zip": { "maxLength": 255, "type": "string", "description": "Sender's postal code. Example:`50142`" }, "city": { "maxLength": 256, "type": "string", "description": "Name of the place of residence (e.g., town, city, or other settlement type) in the address of the payment sender. Example:`Florence`" }, "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Sender's country code in the ISO 3166-1 alpha-2 format. Example: `GB`" }, "state": { "type": "string", "maxLength": 256, "description": "Sender's state" } }, "description": "Object that contains information about the sender" }, "SenderInfoPayout": { "allOf": [ { "$ref": "#/components/schemas/SenderInfo" }, { "$ref": "#/components/schemas/Descriptor" }, { "type": "object", "properties": { "funding_ips_id": { "type": "string", "maxLength": 50, "description": "Transaction ID from from a preceding AFT" } } } ] }, "SenderInfoSale": { "allOf": [ { "$ref": "#/components/schemas/SenderInfo" }, { "$ref": "#/components/schemas/Descriptor" } ] }, "SessionGeneralInfo": { "required": [ "display_name", "domain_name", "project_id", "signature", "validation_url" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" }, "validation_url": { "type": "string", "description": "URL received during the integration through Apple Pay JS API. Example: `https://apple-pay-gateway.apple.com/paymentservices/startSession`" }, "domain_name": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Domain name of the merchant's web service. Example: `appay.eu.ngrok.io`" }, "display_name": { "type": "string", "minLength": 1, "maxLength": 64, "description": "Name of the merchant store to display. This parameter is provided in UTF-8 encoding. Example: `Cosmoshop`" } }, "description": "Object that contains parameters for initiating an Apple Pay session" }, "SessionResponse": { "required": [ "merchantSession" ], "type": "object", "properties": { "merchantSession": { "type": "object", "description": "Object that contains the merchant session information" } }, "description": "Object that contains Apple Pay session information" }, "ShippingInfo": { "type": "object", "properties": { "type": { "type": "string", "pattern": "^0[1-7]$", "description": "Delivery type" }, "delivery_time": { "type": "string", "pattern": "^0[1-4]$", "description": "Delivery time. Possible values: `01`—digital same day delivery, `02`—same day delivery, `03`—next day delivery, `04`—delivery more than one day after the purchase was made" }, "delivery_email": { "type": "string", "maxLength": 255, "description": "Email to deliver purchased digital content to if the customer chooses email delivery", "format": "email" }, "address_usage": { "type": "string", "pattern": "^\\d{2}-\\d{2}-\\d{4}$", "description": "Date when the specified shipping address was used for the first time in DD-MM-YYYY format" }, "name_indicator": { "type": "string", "pattern": "^0[1-2]$", "description": "Indicator whether the customer's name matches the recipient's name. Possible values: `01`—names match, `02`—names do not match" }, "city": { "type": "string", "maxLength": 50, "description": "City from delivery address" }, "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "Country code from delivery address in ISO 3166-1 alpha-2 format" }, "address": { "type": "string", "maxLength": 150, "description": "Street from delivery address" }, "postal": { "type": "string", "maxLength": 16, "description": "Index from delivery address" }, "address_usage_indicator": { "type": "string", "pattern": "^0[1-4]$", "description": "Indicator whether the shipping address used for this transaction was first used with the 3DS Requestor" }, "region_code": { "type": "string", "pattern": "^[0-9A-Z]{1,3}$", "description": "The region or state code of the customer billing address in ISO 3166-2 format. For example, `CA` in US or `ON` for Canada" } }, "description": "An object that contains information about delivery" }, "SkrillCustomerInfo": { "allOf": [ { "$ref": "#/components/schemas/CustomerInfo" }, { "type": "object", "properties": { "id": { "type": "string", "maxLength": 255, "description": "Customer identifier unique within the project" }, "subject": { "type": "string", "maxLength": 250, "description": "Subject line of the email notification sent to the customer" }, "note": { "type": "string", "maxLength": 2000, "description": "Textual comment included in the email notification sent to the customer. Can be used for providing additional information" } }, "required": [ "id" ] } ] }, "SourceInfo": { "type": "integer", "properties": { "id": { "type": "integer", "enum": [ 7 ], "description": "Interface type which is used for payment performing: 7 - Payment Page in iframe mode" }, "user": { "type": "string", "maxLength": 255, "format": "email", "description": "User's email from the source" } }, "required": [ "id" ] }, "StoredCardType": { "type": "integer", "minimum": 0, "maximum": 6, "description": "Indicator of a credential-on-file (COF) purchase type. For more information, see [COF purchases](https://developers.ecommpay.com/en/en_Gate__payments_on_saved_data.html)" }, "Sum": { "type": "object", "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Amount in minor currency units" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Currency code in ISO 4217 alpha-3 format" } }, "description": "Object that contains the amount and currency" }, "TokenData": { "required": [ "token_type" ], "type": "object", "properties": { "token_type": { "type": "string", "enum": [ "network_token" ], "description": "Indicator specifying the type of the token" }, "cryptogram": { "type": "string", "minLength": 28, "maxLength": 28, "description": "Network token verification code, received when the token is collected from the card network" }, "eci": { "type": "string", "maxLength": 2, "enum": [ "01", "02", "05", "06", "07" ], "description": "The ECI that corresponds to the network token, received when the token is collected from the card network" }, "trid": { "type": "string", "minLength": 11, "maxLength": 11, "description": "Identifier of the merchant assigned when the merchant registers in the card network service for creating network tokens" } } }, "TokenizeCustomerInfo": { "description": "Object that contains the customer details", "allOf": [ { "$ref": "#/components/schemas/CustomerInfoBase" }, { "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of the project for managing the interactions of the web service with the payment platform. This identifier is assigned by Ecommpay during the integration. Example: `57123`", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature used for signing the request parameters. Should be generated using the appropriate algorithm after all relevant parameters have been specified. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } }, "required": [ "project_id", "signature" ] } ] }, "TransactionStatusResponse": { "required": [ "general", "status" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "$ref": "#/components/schemas/PaymentResultInfo" }, "customer": { "$ref": "#/components/schemas/CustomerInfo" }, "request_id": { "type": "string" }, "transaction": { "type": "object", "properties": { "id": { "type": "integer" }, "type": { "type": "string" }, "date": { "type": "string", "description": "Date and time when the operation status was most recently updated in the payment platform, in ISO 8601 format" } }, "description": "Object that contains information about processing of the payment in the payment platform" }, "status": { "type": "string" }, "sum_request": { "$ref": "#/components/schemas/Sum" }, "sum_real": { "$ref": "#/components/schemas/Sum" }, "sum_refund": { "$ref": "#/components/schemas/Sum" }, "description": { "type": "string", "description": "Description of the payment" }, "operations": { "type": "array", "items": { "type": "object", "properties": { "id": { "type": "integer" }, "type": { "type": "string" }, "status": { "type": "string" }, "date": { "type": "string" }, "sum": { "$ref": "#/components/schemas/Sum" } } } }, "acs": { "required": [ "acs_url", "md", "pa_req" ], "type": "object", "properties": { "pa_req": { "type": "string", "description": "Payer Authentication Request message received during the 3‑D Secure authentication" }, "md": { "type": "string", "description": "Merchant data received from a global card network during the 3‑D Secure authentication" }, "acs_url": { "type": "string", "description": "URL of the page to which the customer is redirected for the 3‑D Secure authentication (Access Control Server page)" } }, "description": "Object that contains data required to redirect to the 3-D Secure authentication page" }, "return_url": { "type": "string" }, "errors": { "type": "array", "items": { "$ref": "#/components/schemas/ErrorItem" } } } } } }, "tags": [ { "name": "Card payments" }, { "name": "Payment links" }, { "name": "Payment Page payouts" }, { "name": "Token operations" }, { "name": "Additional information submission" }, { "name": "Verification of Payee Service" }, { "name": "ADVCash" }, { "name": "Apple Pay" }, { "name": "ATM" }, { "name": "Bancontact" }, { "name": "Banks" }, { "name": "Bank Transfer" }, { "name": "Blik" }, { "name": "BNPL" }, { "name": "Cash in Kazakhstan" }, { "name": "China UnionPay" }, { "name": "Direct Debit" }, { "name": "EcoPayz" }, { "name": "Flutterwave" }, { "name": "Google Pay" }, { "name": "Interac E-Transfer" }, { "name": "M-Pesa" }, { "name": "Mobile" }, { "name": "Neosurf" }, { "name": "Neteller" }, { "name": "Online Banking" }, { "name": "Pix" }, { "name": "Skrill" }, { "name": "Turkey QR" }, { "name": "Wallet" }, { "name": "Requests for customer details" }, { "name": "Requests for information" }, { "name": "Requests for recurring" }, { "name": "Requests for refunding specific payments" } ] } --- # Dashboard {#en_dbl_about} A section with information about working with Dashboard, an interface intended for use by merchant employees, and the Data API for retrieving operation data. This section provides the information about working with the Dashboard interface. ## Overview and getting started {#section_b5y_grc_c5b .section} The information about the Dashboard interface and how to start using it: - [Overview](en_dbl_overview.md#)introduces the interface, its special characteristics, and how to access it. - [Core capabilities and role-based access model](en_dbl_roles_overview.md#)covers core capabilities, supported access roles and their specific characteristics as well as distribution of access rights to different roles. - [Interaction with the interface](en_dbl_interfaces.md#)describes essential interface elements: main menu, sections, and lists. - [Managing projects](en_dbl_projects.md#)goes over individual settings of your projects you can configure in Dashboard and working with callback settings. ## Working with the interface {#section_wn2_vrc_c5b .section} The information about a range of tasks that Dashboard allows you to accomplish and the necessary instructions: - [Monitoring and performing payments](en_dbl_payments.md#)covers monitoring payments, performing various types of purchases, refunds, and payouts as well as managing regular COF purchases \(subscriptions\) via Dashboard. - [Financial accounting](en_dbl_balances.md#)discusses balances and the special aspects of their use as well as monitoring balances via Dashboard. - [Risk management](en_dbl_risks.md#)introduces the basics of risk management and goes over monitoring fraudulent operations and using whitelists and blacklists via Dashboard. ## Related interfaces {#section_q21_bsc_c5b .section} The information about features and technical aspects of the Data API interface that allows you to get data about operations, chargebacks, and balances–[Using Data API](en_dbl_api_protocol.md). - **[Overview](en_dbl_overview.md#)** An article with the introductory information about the Dashboard interface, its special aspects and access model. - **[Core capabilities and role-based access model](en_dbl_roles_overview.md#)** An article about core capabilities of Dashboard, supported access roles, and distribution of access rights to different roles. - **[Interaction with the interface](en_dbl_interfaces.md#)** An article about working with the essential interface elements of Dashboard: main menu, sections, and lists. - **[Managing projects](en_dbl_projects.md#)** An article about the capabilities of configuring project settings in Dashboard, including callback settings and Apple Pay domain verification. - **[Monitoring and performing payments](en_dbl_payments.md#)** An article about the capabilities of monitoring payments, performing various types of purchases, refunds, and payouts as well as managing regular COF purchases \(subscriptions\) via Dashboard. - **[Receiving financial statements via email](en_dbl_financial_statements.md)** - **[Financial accounting](en_dbl_balances.md#)** An article about balances for working with the platform and the special aspects of their use as well as monitoring balances and currency exchange rates and working with bank accounts via Dashboard. - **[Risk management](en_dbl_risks.md#)** An article about risk management in ecommerce and the capabilities of monitoring fraudulent operations and configuring blacklists via Dashboard. - **[Working with chargeback callbacks](en_dbl_chargeback_callbacks.md#)** An article about the capabilities of working with callbacks that communicate information about events occurring within the chargeback process. - **[Using Data API](en_dbl_api_protocol.md)** Articles about the capabilities and technical specifics of the Data API that allows retrieving information about operations, chargebacks, and balances. - **[Data API](data_api.md)** The Data API specification with the descriptions of data structures and schemas for generating requests to different endpoints. --- # Using Data API {#en_dbl_api_protocol} Articles about the capabilities and technical specifics of the Data API that allows retrieving information about operations, chargebacks, and balances. This section covers using the Data API—an API of the Ecommpay payment platform which allows retrieving information about operations, chargebacks, and balances of your projects. This section includes the following articles: - [Overview](en_dbl_api_overview.md)introduces the Data API interface, its features, and how to use it. - [Interaction concepts](en_dbl_api_interaction.md#)describes main principles of the interaction between the payment platform and the Data API and the workflow of obtaining the data you need. - [Retrieving data](en_dbl_using_api.md#)focuses on working with individual endpoints in the Data API, with the description of data structures and examples. Interface specification is available at [https://api-data.ecommpay.com](https://api-data.ecommpay.com/). - **[Overview](en_dbl_api_overview.md)** An article with the introductory information about the Data API and its capabilities. - **[Interaction concepts](en_dbl_api_interaction.md#)** An article about main principles of the interaction between the payment platform and the Data API and the workflow of obtaining required data. - **[Retrieving data](en_dbl_using_api.md#)** An article about working with individual endpoints in the Data API, with the description of data structures and examples of requests and responses. **Parent topic:**[Dashboard](en_dbl_about.md) --- # Overview {#en_dbl_api_overview} An article with the introductory information about the Data API and its capabilities. The Data API is an API of the Ecommpay payment platform which allows retrieving balance information, chargeback data, operation data and fraudulent operation data with regard to the access rights to certain projects of the merchant and the specified conditions \(such as the type of the operation and the time when it was performed\). Access rights are determined via the specialized tokens of the Dashboard user accounts while the conditions of data retrieval are specified directly in the API requests. The Data API is available at `https://data.ecommpay.com/v1` and allows accepting requests at specified endpoints with the use of HTTP, version 1.1 or higher, and the TLS protocol, version 1.2 or higher. Interface specification is available at [https://api-data.ecommpay.com](https://api-data.ecommpay.com/). To work with the Ecommpay payment platform using the Data API, the merchant needs to: 1. Make sure the requests can be sent and the responses can be received according to the Data API specification. 2. Authorize users who require access to the Data API to generate API tokens and secret keys in the Dashboard interface. 3. Test and deploy the developed solutions into production. **Parent topic:**[Using Data API](en_dbl_api_protocol.md) --- # Data API {#data_api} **Up one level:**[Using Data API](en_dbl_api_protocol.md) { "swagger": "2.0", "info": { "version": "2.1.1", "title": "Data API", "description": "Ecommpay Data API is an interface for retrieving information about merchant operations in the payment platform." }, "host": "data.ecommpay.com", "basePath": "/v1", "schemes": [ "https" ], "paths": { "/balance/get": { "post": { "operationId": "POST_balance-get", "summary": "/balance/get", "tags": [ "Balance" ], "description": "Request to retrieve merchant contracts balances.", "consumes": [ "application/json" ], "parameters": [ { "name": "body", "in": "body", "schema": { "type": "object", "properties": { "token": { "type": "string", "description": "Token generated by Ecommpay Dashboard for user account." }, "signature": { "type": "string", "description": "Digital signature generated by using secret key associated with the token specified in the token parameter." } }, "required": [ "token", "signature" ] }, "x-examples": { "application/json": { "token": "ZOyTL5shY8ddhpxdQyplRPJYmGV7Kv", "signature": "dQcIbv94Z0nPTYX9glSCi...jqInXYrY9zkfcBGQ==" } } } ], "responses": { "200": { "description": "OK", "schema": { "$ref": "#/definitions/ApiBalanceList" }, "examples": { "application/json": { "balance": [ { "name": "Project_Cosmo1_balance_USD", "USD": "1010750" }, { "name": "Project_Cosmo1_balance_SGD", "SGD": "310099" }, { "name": "Project_Cosmo1_balance_EUR", "EUR": "113128" } ], "signature": "3XOq69...OKvPLwQQrRtwxFy5gTz1ggQkoMK9tw5w==" } } }, "400": { "description": "Validation error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "401": { "description": "Authentication error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "429": { "description": "Request rate error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "500": { "description": "Internal server error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } } } } }, "/chargeback/get": { "post": { "operationId": "POST_chargeback_get", "summary": "/chargeback/get", "tags": [ "Chargeback" ], "description": "Request to retrieve a single chargeback data.", "parameters": [ { "name": "body", "in": "body", "schema": { "type": "object", "properties": { "token": { "type": "string", "description": "Token generated in the Ecommpay Dashboard for the user account." }, "signature": { "type": "string", "description": "Digital signature generated by using secret key associated with the token specified in the token parameter." }, "filter": { "type": "object", "description": "Object used for finding a chargeback by various identifiers. The request must contain one of the following identifiers.", "properties": { "chargeback_id": { "type": "integer", "description": "Chargeback ID provided by Ecommpay." }, "arn": { "type": "string", "description": "Acquirer reference number used for clearing." }, "operation_id": { "type": "integer", "description": "Operation ID provided by Ecommpay." } } } }, "required": [ "token", "signature" ] }, "x-examples": { "example-1": { "token": "r8u26__LapNUP5rPIiOuVaMFiwPWI3", "chargeback_id": 11201, "arn": "74312342013012340041234", "operation_id": 1234123412345, "signature": "DNqOZOCxNlXu3bENrDPuEE8...fSJLWDNM/CE8==" } } } ], "responses": { "200": { "description": "OK", "schema": { "type": "object", "properties": { "signature": { "type": "string" }, "chargeback": { "$ref": "#/definitions/Chargeback" } } }, "examples": { "example-1": { "chargeback": { "chargeback_id": "11201", "charged_amount": "50.00", "channel_amount": "50.00", "case_id": "142", "project_id": "1234", "operation_id": "12330123485431", "report_date": "2024-01-31", "respond_by": "2024-02-04 23:59:59", "rev_date": "null", "tr_date_time": "2024-01-13 17:00:56", "chb_completed_at": "2024-02-21 00:00:00", "chb_amount": "50.00", "chb_settlement_amount": "50.00", "rev_indicator": "null", "chb_ccy": "USD", "chb_settlement_ccy": "USD", "charged_currency": "USD", "channel_currency": "USD", "eci_sli": "7", "reason_code": "10.4", "card_type": "VISA", "merchant_id": "10000123", "card": "431422******0056", "arn": "74312342013012340041234", "status": "string", "chb_amount_in_usd": "WON", "merchant_name": "Cosmoshop_on_Mars", "order_id": "1234123412345", "operation_type": "sale", "auth_code": "061230", "card_holder": "JANE DOE", "issuer_country": "UK", "chargeback_stage": "Arbitration", "pre_arbitration_report_date": "2024-02-06", "pre_arbitration_amount": "50.00", "pre_arbitration_ccy": "USD", "arbitration_report_date": "2024-03-06", "arbitration_amount": "50.00", "arbitration_ccy": "USD", "representment_amount": "50.00", "representment_ccy": "USD" }, "signature": "lSiQYO06cTBi5Hos2/sWjWOZocZhdDrzx10vzg/gtmmKfB2g==" } } }, "400": { "description": "Validation error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "401": { "description": "Authentication error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "429": { "description": "Request rate error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "500": { "description": "Internal server error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } } } } }, "/chargeback/list": { "post": { "operationId": "POST_chargeback_list", "summary": "/chargeback/list", "tags": [ "Chargeback" ], "description": "Request to retrieve the list of chargebacks.", "parameters": [ { "name": "body", "in": "body", "schema": { "type": "object", "properties": { "token": { "type": "string", "description": "Token generated in the Ecommpay Dashboard for the user account.\t" }, "signature": { "type": "string", "description": "Digital signature generated by using secret key associated with the token specified in the token parameter." }, "filter": { "type": "object", "description": "Object used for filtering chargeback data by various parameters.\n\nThe first three parameters are specified as time intervals and refer to different dates. The report_date parameter specifies the date when the chargeback was registered in the payment platform (format: \"YYYY-MM-DD\"). The respond_by parameter specifies the deadline for submitting a response to the chargeback (format: \"YYYY-MM-DD HH-MM-SS\"). The chb_completed_at parameter specifies the date when the chargeback received one of the final statuses (format: \"YYYY-MM-DD HH-MM-SS\").\n\nThe rest of the parameters can be passed as an array (if you need to pass one or more values) and as a string (if you need to pass a single value). If the array is omitted, the payment platform returns information for all available values.", "properties": { "report_date": { "$ref": "#/definitions/DateRange" }, "respond_by": { "$ref": "#/definitions/DateRange" }, "chb_completed_at": { "$ref": "#/definitions/DateRange" }, "project_id": { "type": "array", "description": "One or more project IDs provided by Ecommpay.", "items": { "type": "string" } }, "chargeback_id": { "description": "Chargeback ID (as a string) or an array of one or more chargeback IDs.", "type": [ "string", "array" ], "items": { "type": "string" } }, "chargeback_stage": { "description": "Chargeback stage (as a string) or an array of one or more chargeback stages.", "type": [ "string", "array" ], "items": { "type": "string" } }, "arn": { "description": "ARN (as a string) or an array of one or more ARNs. Acquirer reference number used for clearing.", "type": [ "string", "array" ], "items": { "type": "string" } }, "card": { "description": "Card number (as a string) or an array of one or more card numbers used by the customers.", "type": [ "string", "array" ], "items": { "type": "string" } }, "card_type": { "description": "Bank card type (as a string) or an array of one or more bank card types.", "type": [ "string", "array" ], "items": { "type": "string" } }, "reason_code": { "type": [ "string", "array" ], "description": "Numerical chargeback reason code (as a string) or an array of one or more reason codes.", "items": { "type": "string" } }, "operation_id": { "description": "Disputed operation ID provided by Ecommpay or an array of one or more IDs.", "type": [ "string", "array" ], "items": { "type": "string" } }, "status": { "description": "Current status of the chargeback (as a string) or an array of one or more statuses.", "type": [ "string", "array" ], "items": { "type": "string" } } } }, "pagination": { "type": "object", "description": "Object used to restrict the number of chargebacks which are returned in a single response.", "properties": { "limit": { "type": "integer", "description": "Number of entries to return per request. Default value is 20. Maximum value is not set." }, "offset": { "type": "integer", "description": "Pagination start offset. Specifies the number of entries to skip, before starting to return entries. Default value is 0." } } } }, "required": [ "token", "signature" ] }, "x-examples": { "example-1": { "token": "r8u26__LapNUPhbhc000VaMFiwPWI3", "filter": { "chargeback_id": [ 44661, 93028 ] }, "signature": "cNIomz5eEZglWmGOQhcpV...vtWQQglfaDhJsUVujIA==" } } } ], "responses": { "200": { "description": "OK", "schema": { "$ref": "#/definitions/ChargebackList" }, "examples": { "example-1": { "chargebacks": [ { "chargeback_id": "44661", "charged_amount": "5000", "channel_amount": "5000", "case_id": "10002", "project_id": "900", "operation_id": "50000010000001", "report_date": "2024-01-31", "respond_by": "2024-02-04 23:59:59", "rev_date": null, "tr_date_time": "2024-01-13 17:39:56", "chb_completed_at": "2024-02-21 00:00:00", "chb_amount": "50.00", "chb_settlement_amount": "50.00", "rev_indicator": null, "chb_ccy": "USD", "chb_settlement_ccy": "USD", "charged_currency": "USD", "channel_currency": "USD", "eci_sli": "7", "reason_code": "10.4", "card_type": "VISA", "merchant_id": "70000004", "card": "400000******0119", "arn": "70000022010000100000003", "status": "WON", "chb_amount_in_usd": "50.0000", "merchant_name": "COSMOSHOP", "order_id": "3245678KSDFVGK", "operation_type": "sale", "auth_code": "000010", "card_holder": "COSMO USER", "issuer_country": "GB", "chargeback_stage": "Arbitration", "pre_arbitration_report_date": "2024-02-06", "pre_arbitration_amount": "50.00", "pre_arbitration_ccy": "USD", "arbitration_report_date": "2024-03-06", "arbitration_amount": "50.00", "arbitration_ccy": "USD", "representment_amount": "50.00", "representment_ccy": "USD" }, { "chargeback_id": "93028", "charged_amount": "5000", "channel_amount": "5000", "case_id": "14000", "project_id": "900", "operation_id": "67000010000001", "report_date": "2024-01-31", "respond_by": "2024-02-04 23:59:59", "rev_date": null, "tr_date_time": "2024-01-12 12:22:07", "chb_completed_at": "2024-02-21 00:00:00", "chb_amount": "50.00", "chb_settlement_amount": "50.00", "rev_indicator": null, "chb_ccy": "USD", "chb_settlement_ccy": "USD", "charged_currency": "USD", "channel_currency": "USD", "eci_sli": "7", "reason_code": "10.4", "card_type": "VISA", "merchant_id": "70000001", "card": "431422******0056", "arn": "70000022010000100000006", "status": "WON", "chb_amount_in_usd": "50.0000", "merchant_name": "COSMOSHOP", "order_id": "8327588FDJNFIH", "operation_type": "sale", "auth_code": "000005", "card_holder": "COSMO USER", "issuer_country": "GB", "chargeback_stage": "Arbitration", "pre_arbitration_report_date": "2024-02-06", "pre_arbitration_amount": "50.00", "pre_arbitration_ccy": "USD", "arbitration_report_date": "2024-03-06", "arbitration_amount": "50.00", "arbitration_ccy": "USD", "representment_amount": "50.00", "representment_ccy": "USD" } ], "hasMoreRows": false, "signature": "t5BfDi85Hos2/sWjWOZocZhdDrzx10vzg/gtmmKfB2g==" } } }, "400": { "description": "Validation error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "401": { "description": "Authentication error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "429": { "description": "Request rate error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "500": { "description": "Internal server error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } } } } }, "/fraud/list": { "post": { "operationId": "POST_fraud_list", "summary": "/fraud/list", "tags": [ "Fraud" ], "description": "Request to retrieve the list of operations deemed as fraudulent by external payment providers.", "parameters": [ { "name": "body", "in": "body", "schema": { "type": "object", "properties": { "token": { "type": "string", "description": "Token generated in the Ecommpay Dashboard for the user account." }, "signature": { "type": "string", "description": "Digital signature generated by using secret key associated with the token specified in the token parameter." }, "filter": { "type": "object", "description": "Object used for filtering chargeback data by various parameters. \n", "properties": { "received_on": { "type": "array", "description": "Timeframe within which the payment platform registered the information that the card network reported the operation as fraudulent. The array must contain start and end dates specified in 24-hour format of the time period for which the data is retrieved. Format: [YYYY-MM-DD HH:MM:SS,YYYY-MM-DD HH:MM:SS].", "items": { "type": "string" } }, "purchase_date": { "type": "array", "description": "Timeframe within which the operation was completed. The array must contain start and end dates specified in 24-hour format of the time period for which the data is retrieved. By default, the response returns 20 most recently completed operations that are deemed fraudulent. Format: [YYYY-MM-DD HH:MM:SS,YYYY-MM-DD HH:MM:SS].", "items": { "type": "string" } }, "fraud_report_date": { "type": "array", "description": "Timeframe within which the operation was reported as fraudulent to the issuer. The array must contain start and end dates specified in 24-hour format of the time period for which the data is retrieved. By default, the response returns 20 operations most recently reported as fraudulent. Format: [YYYY-MM-DD HH:MM:SS,YYYY-MM-DD HH:MM:SS].", "items": { "type": "string" } }, "issuer_country": { "type": "array", "description": "Country code of the card issuer. An array of one or more codes specified in the ISO 3166-1 alpha-2 format ([Country codes](https://developers.ecommpay.com/en/en_country_codes.html)).", "items": { "type": "string" } }, "has_chargebacks": { "type": "integer", "description": "Indicator that specifies if at least one chargeback was registered in the payment platform for the operation that is deemed fraudulent. Possible values: 0—none registered, 1—one or more registered." }, "customer_id": { "description": "Identifier of the customer in the merchant's project (as a string) or an array of one or more customer identifiers.", "type": [ "string", "array" ], "items": { "type": "string" } }, "card_type": { "description": "Code identifying the card network. Possible values: mc—Mastercard, visa—Visa. Can also be passed as an array with one or both supported values.", "type": [ "string", "array" ], "items": { "type": "string" } } } }, "pagination": { "type": "object", "description": "Pagination is used to restrict the number of fraud operations information about which is returned in a single response.", "properties": { "limit": { "type": "integer", "description": "Number of entries to return per request. Default value is 20. Maximum value is not set." }, "offset": { "type": "integer", "description": "Pagination start offset. Specifies the number of entries to skip, before starting to return entries. Default value is 0." } } } }, "required": [ "token", "signature" ] }, "x-examples": { "example-1": { "token": "ZOyTL5shYsdhpxdQdfdfJYmGV7Kv", "signature": "sd0fr5YxcVmJ...grkglpeXJg==", "filter": { "purchase_date": [ "2025-12-31 00:00:00", "2026-01-07 23:59:59" ], "fraud_report_date": [ "2026-01-01 00:00:00", "2026-01-01 23:59:59" ], "issuer_country": [ "GB", "FR" ] }, "pagination": { "limit": 1000 } } } } ], "responses": { "200": { "description": "OK", "schema": { "$ref": "#/definitions/FraudApiOperationsList" }, "examples": { "example-1": { "operations": [ { "payment_id": "cosmopayment15_rogd", "operation_id": 6435212162442, "tr_amount": "180.00", "tr_ccy": "GBP", "account_number": "424242******4242", "payment_method_type": "visa", "row_updated_at": "2026-01-01 05:30:30", "customer_id": "earthling1232442", "project_name": "cosmoshop.earth", "project_id": "123", "arn": "14736364365402210100727", "fraud_type": "6", "fraud_report_date": "2026-01-01", "issuer_country": "GB", "received_on": "2026-01-01", "purchase_date": "2025-12-31", "channel_amount_in_usd": "234.58", "issuer_bank_name": "Intergalactic Bank", "bin": "123456", "country_by_ip": "GB", "customer_email": "earthling@earth.earth", "report_and_purchase_date_difference": 2 } ], "signature": "k4iXC84dfwevT+...dS056fssBGIw==" } } }, "400": { "description": "Validation error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "401": { "description": "Authentication error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "429": { "description": "Request rate error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "500": { "description": "Internal server error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } } } } }, "/financial-reporting/operations": { "post": { "operationId": "POST_financial-reporting-operations", "summary": "/financial-reporting/operations", "description": "Request to retrieve itemised operation data for financial reporting (including charged fees) for a specified time period. These data are accurate and can be used for reconciliation.", "parameters": [ { "name": "body", "in": "body", "schema": { "type": "object", "required": [ "token", "signature", "operation_completed_at", "tz" ], "properties": { "token": { "type": "string", "description": "Token generated in the Ecommpay Dashboard for the user account." }, "signature": { "type": "string", "description": "Digital signature generated by using a secret key associated with the token specified in the token parameter." }, "operation_completed_at": { "type": "object", "description": "Time period with the start and end times for which to retrieve data. Only data about operations completed in the payment platform within the last 30 days can be requested.", "required": [ "from", "to" ], "properties": { "from": { "type": "string", "description": "Start time in the YYYY-MM-DD hh:mm:ss format." }, "to": { "type": "string", "description": "End time in the YYYY-MM-DD hh:mm:ss format." } } }, "tz": { "type": "string", "description": "Identifier of the time zone for the time period. The time zone affects what operations will be selected for the time period specified in the operation_completed_at object. Can be one of the names in the IANA time zone database (for example, Indian/Mauritius) or the UTC offset (for example, +10:30)." }, "project_id": { "type": "array", "description": "Array of one or more project identifiers. If the array is omitted, the response will contain information for all projects accessible for the user account which is associated with the token specified in the token parameter.", "items": { "type": "integer" } }, "provider_id": { "type": "array", "description": "Array of one or more provider identifiers. If the array is omitted, the response will contain information for all providers available for the user account which is associated with the token specified in the token parameter.", "items": { "type": "integer" } }, "operation_id": { "type": "array", "description": "Array of one or more payment operation identifiers provided by Ecommpay. If the array is omitted, the response will contain information for all projects accessible for the user account which is associated with the token specified in the token parameter.", "items": { "type": "integer" } }, "limit": { "type": "integer", "description": "Number of entries to return per request. The default value, which is also the maximum, is 1000." }, "offset": { "type": "integer", "description": "Pagination start offset. Specifies the number of entries to skip before starting to return entries. Default value is 0." } } }, "x-examples": { "application/json": { "project_id": [ 11 ], "operation_completed_at": { "from": "2024-01-01 00:00:00", "to": "2024-01-31 23:59:59" }, "tz": "Indian/Mauritius", "limit": 1000, "offset": 0, "token": "ZOyTL5shY8ddhpxdQyplRPJYmGV7Kv", "signature": "YsrkgdBr5peXJgJ...glVmsd0f==" } } } ], "responses": { "200": { "description": "OK", "schema": { "$ref": "#/definitions/ApiFinancialOperationsList" }, "examples": { "application/json": { "data": [ { "operation_completed_at": "2024-01-29T22:08:19+0000", "transaction_id": "81194009089601", "operation_id": "81194009122865", "provider_payment_id": "0040000028207224", "payment_id": "1994-1312", "arn": "70114165164100000032195", "rrn": "451912040334", "auth_appr_code": "611887", "provider_id": "120461", "provider_name": "Provider name", "payment_description": "purchase", "operation_type": "sale", "operation_status": "success", "tran_region": "domestic", "tariff_region": "EU", "proc_region": "Visa Europe", "security_level": "SEC", "operation_amount": 2098, "operation_currency": "GBP", "billing_conversion_rate": 0, "billing_amount": 2098, "billing_currency": "GBP", "total_interchange_fee": -4.2, "total_scheme_fee": -0.64, "auth_msc_fee": 0, "clearing_msc_fee": -3.785649, "total_msc_fee": -3.78, "hold_amount": 0, "project_id": 11, "project_url": "https://www.company.com", "merchant_name": "COMPANY NAME", "mid": "70000000", "terminal_id": "70000000", "mcc_code": "4722", "legal_country": "GB", "payment_method_name": "visa", "product_type": "Consumer", "account_funding_source": "debit", "account_number": "475144******1111", "card_product": "Visa classic", "issuer_country": "GB", "customer_id": "1436462", "card_holder": "CARD HOLDER" } ], "signature": "fdsfdsf985np=..." } } }, "400": { "description": "Validation error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "401": { "description": "Authentication error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "429": { "description": "Request rate error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "500": { "description": "Internal server error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } } }, "tags": [ "Operations" ] } }, "/operations/get": { "post": { "operationId": "POST_operations-get", "summary": "/operations/get", "tags": [ "Operations" ], "description": "Request to retrieve itemised operation data for a specified time period. These data can be used for general purposes of monitoring and anaysis.", "consumes": [ "application/json" ], "parameters": [ { "name": "body", "in": "body", "schema": { "type": "object", "properties": { "project_id": { "type": "array", "description": "Array of one or more project IDs. If array is omitted, the payment platform returns information for all projects accessible for the user account which is associated with the token specified in the token parameter.", "items": { "type": "integer" } }, "interval": { "type": "object", "description": "Time period with start and end times for which to retrieve data. By default, the response returns operations most recently completed.\r\nIf more than one request is received in the platform from a single Dashboard user account within 10 seconds and the time period for which the information is requested exceeds 180 days, these requests are processed one by one, with 10 seconds timeouts.", "properties": { "from": { "type": "string", "description": "Start time in the YYYY-MM-DD hh:mm:ss format.\r\n" }, "to": { "type": "string", "description": "End time in the YYYY-MM-DD hh:mm:ss format." } }, "required": [ "from", "to" ] }, "tz": { "type": "string", "description": "Identifier of the time zone for the time period. If the request does not contain this parameter, the default is the time zone of the Dashboard user account associated with the token from the token parameter. The time zone affects what operations will be selected for the time period specified in the interval object and the format of time parameters in the response—operation_created_at and operation_completed_at. Can be one of the names in the IANA time zone database (for example, Indian/Mauritius) or the UTC offset (for example, +10:30)." }, "limit": { "type": "integer", "description": "Number of entries to return per request. Maximum and default value is 1000." }, "offset": { "type": "integer", "description": "Pagination start offset. Specifies the number of entries to skip, before starting to return entries. Default value is 0." }, "operation_type": { "type": [ "array", "string" ], "description": "Operation type[s]. One or more operation types supported by the Ecommpay payment platform. The operation_type variable can be passed as an array (if you need to pass one or more values) and as a string (if you need to pass a single value).", "items": { "type": "string" } }, "operation_status": { "type": [ "array", "string" ], "description": "Operation status[es]. One or more operation statuses supported by the Ecommpay payment platform. The operation_status variable can be passed as an array (if you need to pass one or more values) and as a string (if you need to pass a single value).", "items": { "type": "string" } }, "customer_id": { "type": [ "array", "string" ], "description": "Unique customer identifier[s]. One or more unique identifiers of customers in your project. The customer_id variable can be passed as an array (if you need to pass one or more values) and as a string (if you need to pass a single value).", "items": { "type": "string" } }, "customer_email": { "type": "string", "description": "Customer email." }, "token": { "type": "string", "description": "Token generated in Ecommpay Dashboard for user account." }, "fields": { "type": "array", "description": "An array of one or more parameter names the values of which are needed to be returned for each operation in the response. In the array, the parameter names must be enclosed in matching quotation marks and separated by commas and can be specified in an arbitrary order (for example, operation_id, payment_id, project_id). However, in the response the parameter values are returned in the fixed order which, together with the list of parameters, is defined in the response specification. If the array is omitted, then the response contains the values of the required parameters for each operation.", "items": { "type": "string" } }, "signature": { "type": "string", "description": "Digital signature generated by using secret key associated with the token specified in the token parameter." } }, "required": [ "token", "signature" ] }, "x-examples": { "application/json": { "project_id": [ 0, 11 ], "interval": { "from": "2024-08-01 00:00:00", "to": "2024-08-28 23:59:59" }, "limit": 2, "offset": 1000, "operation_type": [ "sale", "refund" ], "operation_status": [ "success", "decline" ], "customer_email": "astronaut@earth.station", "token": "ZOyTL5shY8ddhpxdQyplRPJYmGV7Kv", "fields": [ "operation_id", "operation_type", "operation_status", "sum_initial.amount", "sum_initial.currency", "customer_email" ], "signature": "sd0fr5YsdBVmJ...grkglpeXJg==" } } } ], "responses": { "200": { "description": "OK", "schema": { "$ref": "#/definitions/ApiOperationsList" }, "examples": { "application/json": { "operations": [ { "operation_id": "6435212162442", "operation_type": "sale", "operation_status": "success", "sum_initial": { "amount": 1200, "currency": "USD" }, "customer_email": "astronaut@earth.station" }, { "operation_id": "1232452442", "operation_type": "refund", "operation_status": "success", "sum_initial": { "amount": 5800, "currency": "EUR" }, "customer_email": "astronaut@earth.station" } ], "signature": "k4iXC845FvT+...dS0AH5BGIw==" } } }, "400": { "description": "Validation error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "401": { "description": "Authentication error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "429": { "description": "Request rate error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "500": { "description": "Internal server error", "schema": { "$ref": "#/definitions/ApiErrorResponse" } } } } }, "/operations/get-by-payment": { "post": { "operationId": "POST_operations-get-by-payment", "summary": "/operations/get-by-payment", "tags": [ "Operations" ], "description": "Request to retrieve all the operations performed in the payment platform for specific payment.", "consumes": [ "application/json" ], "parameters": [ { "name": "body", "in": "body", "schema": { "type": "object", "properties": { "payment_id": { "type": "string", "description": "Payment ID in the project." }, "token": { "type": "string", "description": "Token generated by Ecommpay Dashboard for user account." }, "signature": { "type": "string", "description": "Digital signature generated by using secret key associated with the token specified in the token parameter." } }, "required": [ "payment_id", "token", "signature" ] }, "x-examples": { "application/json": { "payment_id": "PID_25467851461-2147", "token": "VmJQhaXILAnZWTKmqwSd3j", "signature": "JM+YWmTL7uGn26IgZWTKmqwSd...tRkvdC0yaq030+eNXVtJjjtgrkglpeXJg==" } } } ], "responses": { "200": { "description": "", "schema": { "type": "object", "description": "List of operations with operation details.", "properties": { "operations": { "type": "array", "items": { "type": "object", "description": "Operation details.", "properties": { "operation_id": { "type": "string", "description": "Payment operation ID provided by Ecommpay." }, "operation_type": { "type": "string", "description": "Operation type. One of operation types supported by the Ecommpay payment platform." }, "operation_created_at": { "type": "string", "description": "Date and time when the operation was created. Format: YYYY-MM-DD hh:mm:ss." }, "operation_completed_at": { "type": "string", "description": "Date and time when the operation was completed in the payment platform. Format: YYYY-MM-DD hh:mm:ss." }, "amount": { "type": "number", "description": "Operation amount in minor currency units." }, "currency": { "type": "string", "description": "Operation currency code. Currency code must comply with ISO 4217 alpha-3." }, "arn": { "type": "string", "description": "Acquirer Reference Number - 23 digits of the unique operation identifier in clearing exchange between banks or processing centers." }, "rrn": { "type": "string", "description": "Reference Retrieval Number - 12 digits of the unique operation identifier, which is assigned by the Acquirer Bank when the payment is initialized." } }, "required": [ "operation_id", "operation_type", "operation_created_at", "operation_completed_at", "amount", "currency", "arn", "rrn" ] } }, "signature": { "type": "string", "description": "Digital signature generated by using secret key of Ecommpay Dashboard user account. The payment platform uses the same key that was previously used to sign the request." } } }, "examples": { "application/json": { "operations": [ { "arn": "", "operation_completed_at": "2024-11-22T13:13:04+00:00", "operation_type": "refund", "operation_id": "2747253065470", "amount": 221, "currency": "USD", "operation_created_at": "2024-11-22T13:13:04+00:00", "rrn": "803817399309" }, { "arn": "", "operation_completed_at": "2024-11-22T13:09:03+00:00", "operation_type": "capture", "operation_id": "2747253065469", "amount": 1621, "currency": "USD", "operation_created_at": "2024-11-22T13:09:03+00:00", "rrn": "000000248370" }, { "arn": "", "operation_completed_at": "2024-11-22T13:06:40+00:00", "operation_type": "auth", "operation_id": "2747253065468", "amount": 2000, "currency": "USD", "operation_created_at": "2024-11-22T13:06:38+00:00", "rrn": "000047769105" } ], "signature": "hsUpqn7QPDxNLNH/ZulaK...z/Hv7NkQFujSnvw==" } } }, "400": { "description": "", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "401": { "description": "", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "429": { "description": "", "schema": { "$ref": "#/definitions/ApiErrorResponse" } }, "500": { "description": "", "schema": { "$ref": "#/definitions/ApiErrorResponse" } } } } } }, "definitions": { "ApiBalanceList": { "title": "ApiBalanceList", "type": "object", "description": "List of balances with balance details.", "properties": { "balance": { "type": "array", "description": "Array of balances.", "items": { "$ref": "#/definitions/BalanceTransactionItem" } }, "signature": { "type": "string", "description": "Digital signature generated by using secret key of Ecommpay Dashboard user account. The payment platform uses the same key that was previously used to sign the request." } } }, "ApiErrorResponse": { "type": "object", "description": "Error details.", "required": [ "status" ], "properties": { "name": { "type": "string", "description": "Error name." }, "message": { "type": "string", "description": "Description of error cause." }, "code": { "type": "integer", "description": "HTTP error code." }, "status": { "type": "integer", "description": "HTTP response code, for example 400 or 401." } } }, "ApiFinancialOperationsList": { "title": "ApiOperationsList", "type": "object", "description": "List of operations with extended data (including charged fees).", "required": [ "data", "signature" ], "properties": { "data": { "type": "array", "items": { "$ref": "#/definitions/FinancialOperationItem" } }, "signature": { "type": "string", "description": "Digital signature generated by using secret key of Ecommpay Dashboard user account. The payment platform uses the same key that was previously used to sign the request." } } }, "ApiOperationsList": { "type": "object", "description": "List of operations with operation details.", "properties": { "operations": { "type": "array", "items": { "$ref": "#/definitions/OperationItem" } }, "signature": { "type": "string", "description": "Digital signature generated by using secret key of Ecommpay Dashboard user account. The payment platform uses the same key that was previously used to sign the request." } } }, "BalanceTransactionItem": { "title": "BalanceTransactionItem", "type": "object", "description": "Balance details.", "properties": { "name": { "type": "string", "description": "Balance name within the contract." }, "{additionalProperties}": { "type": "string", "description": "Currency code and balance amount in minor currency units presented as parameter-value pair, for example: EUR: 5000. Currency code is specified as the parameter name. Balance amount is specified as parameter value." } } }, "Chargeback": { "type": "object", "properties": { "chargeback_id": { "type": "string", "description": "Chargeback ID." }, "charged_amount": { "type": "string", "description": "Amount that has been debited (as shown in the Operational Statement). Specified as an integer in minor currency units." }, "channel_amount": { "type": "string", "description": "Amount of the disputed operation (as originally processed by the merchant). Specified as an integer in minor currency units." }, "case_id": { "type": "string", "description": "Identification number of the chargeback case (the case may include multiple chargebacks)." }, "project_id": { "type": "string", "description": "Merchant project ID assigned by Ecommpay." }, "operation_id": { "type": "string", "description": "Operation ID provided by Ecommpay." }, "report_date": { "type": "string", "description": "Date when the chargeback was registered in the payment platform." }, "respond_by": { "type": "string", "description": "Deadline for submitting a response to the chargeback." }, "rev_date": { "type": "string", "description": "Date when the chargeback reversal was performed, otherwise null.", "x-nullable": true }, "tr_date_time": { "type": "string", "description": "Date and time when the disputed operation occurred." }, "chb_completed_at": { "type": "string", "description": "Date when the chargeback received one of the final statuses: won, lost, returned, accepted by merchant." }, "chb_amount": { "type": "string", "description": "Amount for which the issuer initiated a chargeback. Specified as a decimal number with two decimal places." }, "chb_settlement_amount": { "type": "string", "description": "Chargeback amount in the settlement currency of the acquiring bank. Specified as a decimal number with two decimal places." }, "rev_indicator": { "type": "string", "description": "‘R’ if there was a chargeback reversal received, otherwise null.", "x-nullable": true }, "chb_ccy": { "type": "string", "description": "Currency of the chargeback initiated by the issuer." }, "chb_settlement_ccy": { "type": "string", "description": "Settlement currency of the acquiring bank." }, "charged_currency": { "type": "string", "description": "Currency in which the amount has been debited (as shown in the Operational Statement)." }, "channel_currency": { "type": "string", "description": "Operation amount currency code." }, "eci_sli": { "type": "string", "description": "Electronic Commerce Indicator (for Visa) and Security Level Indicator (for Mastercard)." }, "reason_code": { "type": "string", "description": "Numerical chargeback reason code." }, "card_type": { "type": "string", "description": "Card payments processing organisation, for example, Visa or Mastercard." }, "merchant_id": { "type": "string", "description": "Merchant identifier assigned by Ecommpay at the stage of integration. " }, "card": { "type": "string", "description": "Number of the card used by the customer." }, "arn": { "type": "string", "description": "Acquirer reference number used for clearing. " }, "status": { "type": "string", "description": "Current status of the chargeback." }, "chb_amount_in_usd": { "type": "string", "description": "Chargeback amount in USD. Specified as a decimal number with four decimal places." }, "merchant_name": { "type": "string", "description": "Merchant name passed in the merchant.descriptor parameter." }, "order_id": { "type": "string", "description": "Operation ID provided by Ecommpay." }, "operation_type": { "type": "string", "description": "Operation type. One of the operation types supported by the Ecommpay payment platform." }, "auth_code": { "type": "string", "description": "Operation authorization code. Alphanumeric code which confirms that the card issuer or payment system approved processing of the payment. Authorization codes are not assigned to declined payments." }, "card_holder": { "type": "string", "description": "Name of the cardholder (as specified on the card)." }, "issuer_country": { "type": "string", "description": "Country of the issuer determined according to the BIN of the card. Array of one or more country codes in ISO 3166-1 alpha-2 format ([Country codes](https://developers.ecommpay.com/en/en_country_codes.html))." }, "chargeback_stage": { "type": "string", "description": "Stage at which the work with the chargeback is currently carried out." }, "pre_arbitration_report_date": { "type": "string", "description": "Date when Ecommpay was informed that the issuer initiated the Pre-Arbitration stage." }, "pre_arbitration_amount": { "type": "string", "description": "Amount of the disputed operation at the Pre-Arbitration stage. May differ from the initial disputed amount." }, "pre_arbitration_ccy": { "type": "string", "description": "Currency of the amount at the Pre-Arbitration stage." }, "arbitration_report_date": { "type": "string", "description": "Date when Ecommpay was informed that the issuer initiated the Arbitration stage." }, "arbitration_amount": { "type": "string", "description": "Amount of the disputed operation at the Arbitration stage." }, "arbitration_ccy": { "type": "string", "description": "Currency of the amount at the Arbitration stage." }, "representment_amount": { "type": "string", "description": "The amount that is returned to the merchant if the merchant wins the chargeback at the Representment stage." }, "representment_ccy": { "type": "string", "description": "Currency in which the chargeback amount is returned to the merchant if the merchant wins the chargeback at the Representment stage." } } }, "ChargebackList": { "type": "object", "description": "List of chargebacks.", "title": "", "properties": { "chargebacks": { "type": "array", "items": { "$ref": "#/definitions/Chargeback" } }, "hasMoreRows": { "description": "True if the number of rows is more than 20. Please use pagination.", "type": "boolean" }, "signature": { "type": "string", "description": "Digital signature generated by using secret key of the Ecommpay Dashboard user account. The payment platform uses the same key that was previously used to sign the request." } } }, "DateRange": { "type": "object", "description": "The object must contain start and end dates of the time period for which the data is retrieved.", "properties": { "from": { "type": "string", "description": "Start date of the required time period. " }, "to": { "type": "string", "description": "End date of the required time period." } } }, "FinancialOperationItem": { "title": "OperationItem", "type": "object", "description": " Extended operation data (including charged fees).", "required": [ "operation_completed_at", "transaction_id", "operation_id", "provider_payment_id", "payment_id", "arn", "rrn", "auth_appr_code", "provider_id", "provider_name", "payment_description", "operation_type", "operation_status", "tran_region", "proc_region", "security_level", "operation_amount", "operation_currency", "billing_conversion_rate", "billing_amount", "billing_currency", "total_interchange_fee", "total_scheme_fee", "total_msc_fee", "auth_msc_fee", "clearing_msc_fee", "hold_amount", "project_id", "project_url", "merchant_name", "terminal_id", "mcc_code", "legal_country", "payment_method_name", "product_type", "account_number", "card_product", "issuer_country", "customer_id", "card_holder" ], "properties": { "operation_completed_at": { "type": "string", "description": "Time when the operation was completed in the payment platform, specified according to the time zone passed in the request. Format: YYYY-MM-DD hh:mm:ss." }, "transaction_id": { "type": "string", "description": "Identifier used for referencing a payment transaction in the Ecommpay payment platform. In the payment platform, the payment identifier is unique only within the merchant's project while the transaction identifier is unique within the entirety of the payment platform." }, "operation_id": { "type": "string", "description": "Operation identifier assigned by Ecommpay." }, "provider_payment_id": { "type": "string", "description": "Operation identifier assigned by the external payment system or provider." }, "payment_id": { "type": "string", "description": "Payment identifier within the project assigned by the merchant." }, "arn": { "type": "string", "description": "Acquirer Reference Number: an operation identifier used for clearing. This identifier is assigned by the acquirer and is used for tracking operations." }, "rrn": { "type": "string", "description": "Reference Retrieval Number: an operation number assigned by the acquirer which is used for associating the operation with the payment details for easier retrieval and reconciliation." }, "auth_appr_code": { "type": "string", "description": "Alphanumeric code which confirms that the card issuer or the payment system approved processing of the payment. Authorisation codes are not assigned to declined payments." }, "provider_id": { "type": "string", "description": "Identifier of an external payment system or a provider in the payment platform." }, "provider_name": { "type": "string", "description": "Name of an external payment system or a provider in the payment platform." }, "payment_description": { "type": "string", "description": "Description of the payment as specified in the initial request." }, "operation_type": { "type": "string", "description": "One of the operation types supported by the Ecommpay payment platform." }, "operation_status": { "type": "string", "description": "One of the operation statuses supported by the Ecommpay payment platform." }, "tran_region": { "type": "string", "description": "Region code for the operation ([Region codes](https://developers.ecommpay.com/en/en_region_codes.html))." }, "tariff_region": { "type": "string", "description": "Reference to the region that determines the processing fee rate." }, "proc_region": { "type": "string", "description": "Reference to the region that determines what processing rules are applied to the operation." }, "security_level": { "type": "string", "description": "Reference to the result of the cardholder 3‑D Secure authentication, determined on the basis of the Electronic Commerce Indicator parameter. Can be populated with one of the following values: sec, attempt, non-sec." }, "operation_amount": { "type": "number", "description": "Amount of the initial operation; can be a decimal number." }, "operation_currency": { "type": "string", "description": "Initial operation currency code in the ISO 4217 alpha-3 format." }, "billing_conversion_rate": { "type": "number", "description": "Exchange rate used for the conversion of the operation amount to the billing currency; can be a decimal number and, depending on the pricing model, can also be sent empty." }, "billing_amount": { "type": "number", "description": "Operation amount in the billing currency; can be a decimal number and, depending on the pricing model, can also be sent empty." }, "billing_currency": { "type": "string", "description": "Billing currency code in the ISO 4217 alpha-3 format. Depending on the pricing model, can be sent empty." }, "total_interchange_fee": { "type": "number", "description": "Interchange fee amount; a decimal number, can be positive or negative. Depending on the pricing model, can be sent empty." }, "total_scheme_fee": { "type": "number", "description": "Scheme fee amount; a decimal number, can be positive or negative. Depending on the pricing model, can be sent empty." }, "total_msc_fee": { "type": "number", "description": "Merchant service charge total amount; a decimal number, can be positive or negative. Depending on the pricing model, can be sent empty." }, "auth_msc_fee": { "type": "number", "description": "The portion of the Merchant service charge amount charged for authorisation; a decimal number, can be positive or negative. Depending on the pricing model, can be sent empty." }, "clearing_msc_fee": { "type": "number", "description": "The portion of the Merchant service charge amount charged for clearing; a decimal number, can be positive or negative. Depending on the pricing model, can be sent empty." }, "hold_amount": { "type": "number", "description": "Amount of funds held for the operation; can be a decimal number." }, "project_id": { "type": "integer", "description": "Project identifier provided by Ecommpay." }, "project_url": { "type": "string", "description": "Base URL of the merchant's web service associated with the specific project." }, "merchant_name": { "type": "string", "description": "Name of the merchant within the payment platform." }, "mid": { "type": "string", "description": "Identifier of the merchant assigned by the provider (which includes Ecommpay) or by the acquirer and used for processing card payments." }, "terminal_id": { "type": "string", "description": "Identifier of a logical node in the payment platform that determines the configuration of payment processing properties for a certain MID in specific cases. Assigned within MID." }, "mcc_code": { "type": "string", "description": "Merchant category code. A 4-digit number that classifies the type of the merchant's business activity." }, "legal_country": { "type": "string", "description": "Code of the merchant's country of registration in the ISO 3166-1 alpha-2 format." }, "payment_method_name": { "type": "string", "description": "Identifier of the payment system. For card payments, it is the identifier of the card processing network, for example, Visa or Mastercard. For some payment methods, can be sent empty." }, "product_type": { "type": "string", "description": "Reference to the class of the card product offered by a card processing network, for example, consumer or commercial." }, "account_funding_source": { "type": "string", "description": "Type of the payment card funding, for example, debit, credit, or prepaid." }, "account_number": { "type": "string", "description": "Identifier of the payment instrument used by the customer, for example, a card or a wallet number." }, "card_product": { "type": "string", "description": "Card category offered by the issuing bank, for example, Visa Classic or World Elite Mastercard." }, "issuer_country": { "type": "string", "description": "Country code of the issuer determined according to the BIN of the card in the ISO 3166-1 alpha-2 format." }, "customer_id": { "type": "string", "description": "Identifier of the customer in the merchant's project." }, "card_holder": { "type": "string", "description": "Name of the cardholder as specified in the initial request." } } }, "FraudApiOperationsList": { "title": "FraudApiOperationsList", "type": "object", "description": "List of fraudulent operations.", "properties": { "operations": { "type": "array", "items": { "type": "object", "properties": { "payment_id": { "type": "string", "description": "Payment ID in the project." }, "operation_id": { "type": "integer", "description": "Operation ID provided by Ecommpay." }, "tr_amount": { "type": "string", "description": "Fraudulent operation amount (full operation amount)." }, "tr_ccy": { "type": "string", "description": "Fraudulent operation currency code in ISO 4217 alpha-3 format ([Currency codes](https://developers.ecommpay.com/en/en_currency_codes.html))." }, "account_number": { "type": "string", "description": "Number of the card used by the customer." }, "payment_method_type": { "type": "string", "description": "Type of the payment method used for payment processing." }, "row_updated_at": { "type": "string", "description": "The date and time of the most recent update of the fraudulent operation record in the payment platform." }, "customer_id": { "type": "string", "description": "Identifier of the customer in the merchant's project." }, "project_name": { "type": "string", "description": "Name of the merchant's website (project)." }, "project_id": { "type": "string", "description": "Project ID provided by Ecommpay." }, "arn": { "type": "string", "description": "Acquirer Reference Number: a unique operation identifier in clearing exchange between banks or processing centers." }, "fraud_type": { "type": "string", "description": "Type of fraud declared by the issuer when submitting information about fraudulent operations to payment systems." }, "fraud_report_date": { "type": "string", "description": "Date when the operation was reported as fraudulent to the issuer. Format: [YYYY-MM-DD]." }, "issuer_country": { "type": "string", "description": "Country code of the card issuer determined according to the BIN of the card (two-letter ISO code)." }, "received_on": { "type": "string", "description": "Date when the payment platform registered the information that the card network reported the operation as fraudulent" }, "purchase_date": { "type": "string", "description": "Date when the operation was completed. Format: [YYYY-MM-DD,YYYY-MM-DD]." }, "channel_amount_in_usd": { "type": "string", "description": "Fraudulent operation amount in USD." }, "issuer_bank_name": { "type": "string", "description": "Name of the issuer determined according to the BIN of the card." }, "bin": { "type": "string", "description": "Bank Identification Number that refers to the first six to eight digits of PAN, also known as IIN (Issuer Identification Number)." }, "country_by_ip": { "type": "string", "description": "Country determined according to the IP address of the customer (two-letter ISO country code)." }, "customer_email": { "type": "string", "description": "Customer email address." }, "report_and_purchase_date_difference": { "type": "integer", "description": "The number of full days between fraud report and purchase dates." }, "has_chargebacks": { "type": "integer", "description": "Indicator that specifies if at least one chargeback was registered in the payment platform for the operation that is deemed fraudulent. Possible values: 0—none registered, 1—one or more registered." }, "card_type": { "type": "string", "description": "Code identifying the card network. Possible values: mc—Mastercard, visa—Visa." } } } }, "signature": { "type": "string", "description": "Digital signature generated by using secret key of Ecommpay Dashboard user account. The payment platform uses the same key that was previously used to sign the request." } } }, "OperationItem": { "title": "OperationItem", "type": "object", "description": "Operation details.", "properties": { "project_id": { "type": "string", "description": "Project ID provided by Ecommpay." }, "operation_id": { "type": "string", "description": "Payment operation ID provided by Ecommpay." }, "payment_id": { "type": "string", "description": "Payment ID in the project." }, "operation_type": { "type": "string", "description": "Operation type. One of the operation types supported by the Ecommpay payment platform." }, "operation_status": { "type": "string", "description": "Operation status. One of the operation statuses supported by the Ecommpay payment platform." }, "account_number": { "type": "string", "description": "ID of the payment instrument used by customer, for example, card number or wallet ID." }, "customer_ip": { "type": "string", "description": "Customer IP address." }, "payment_method_name": { "type": "string", "description": "Name of the payment method used for payment processing." }, "payment_method_type": { "type": "string", "description": "Type of the payment method used for payment processing." }, "payment_description": { "type": "string", "description": "Description of the payment as specified in the initial request." }, "operation_created_at": { "type": "string", "description": "Date and time when the operation was created. Format: YYYY-MM-DD hh:mm:ss." }, "operation_completed_at": { "type": "string", "description": "Date and time when the operation was completed in the payment platform. Format: YYYY-MM-DD hh:mm:ss." }, "provider_date": { "type": "string", "description": "Date and time when the operation was completed on the payment provider side. Format: YYYY-MM-DD hh:mm:ss." }, "shipment_date": { "type": "string", "description": "Date and time when the payment provider posted the operation for clearing. Format: YYYY-MM-DD hh:mm:ss." }, "sum_initial": { "type": "object", "description": "Amount and currency code of the operation as specified in the initial request.", "required": [ "amount", "currency" ], "properties": { "amount": { "type": "string", "description": "Operation amount in minor currency units as specified in the initial request." }, "currency": { "type": "string", "description": "Operation currency code as specified in the initial request. Must be the ISO 4217 alpha-3 currency code." } } }, "sum_converted": { "type": "object", "description": "Code of the currency that the payment provider used for performing the operation and the initial amount converted to this currency.", "required": [ "amount", "currency" ], "properties": { "amount": { "type": "string", "description": "Operation amount in minor units of the payment provider currency." }, "currency": { "type": "string", "description": "Code of the currency that the payment provider used for performing the operation. Must be the ISO 4217 alpha-3 currency code." } } }, "arn": { "type": "string", "description": "Acquirer Reference Number: a unique operation identifier in clearing exchange between banks or processing centers." }, "rrn": { "type": "string", "description": "Reference Retrieval Number: a unique operation identifier assigned by the acquirer bank when the payment is initialized." }, "payment_provider_code": { "type": "string", "description": "Numeric code of payment result from the card issuer or payment provider." }, "payment_provider_message": { "type": "string", "description": "Message of payment result from the card issuer or payment provider." }, "acquirer_bank_name": { "type": "string", "description": "Name of the acquirer bank." }, "auth_code": { "type": "string", "description": "Alphanumeric code which confirms that the card issuer / payment system approved processing of the payment. Authorization codes are not assigned to declined payments." }, "avs_post_code": { "type": "string", "description": "Customer postal code for verification with the Address Verification Service. AVS applies to cardholders from the UK, USA, and Canada." }, "avs_result": { "type": "string", "description": "A single-letter Address Verification Service response code sent by the issuer following the address verification. AVS applies to cardholders from the UK, USA, and Canada." }, "avs_street_address": { "type": "string", "description": "Customer postal address for verification with the Address Verification Service. AVS applies to cardholders from the UK, USA, and Canada." }, "balance_id": { "type": "string", "description": "ID of the merchant's balance aggregation in the Ecommpay payment platform under which all merchant accounts are aggregated. This ID is masked by adding id_mask to the initial identifier." }, "bank_name": { "type": "string", "description": "Name of the issuer determined according to the BIN of the card." }, "bin": { "type": "string", "description": "Bank Identification Number (first six to eight digits of PAN). Numeric identifier of the card organization member. Assigned separately to each card level (for example, Classic, Standard, Gold, Maestro, Visa Electron, etc.) offered by the issuing bank—a card organization member. Also referred to as IIN (Issuer Identification Number)." }, "card_enroll_check": { "type": "string", "description": "Specifies if the card supports 3-D Secure. Possible values are: E—Enrolled (the card supports 3DS), N—Not enrolled, U—Undefined (was unable to determine)." }, "card_holder": { "type": "string", "description": "The name of the cardholder (as specified on the card)." }, "card_product_name": { "type": "string", "description": "Name of the bank product determined according to the BIN of the card." }, "card_token": { "type": "string", "description": "Token of the customer bank card in the Ecommpay payment platform." }, "completed_refund": { "type": "string", "description": "Amount of the issued refund in minor units of currency." }, "country_by_ip": { "type": "string", "description": "Country determined according to the IP address of the customer (two-letter ISO country code)." }, "country_by_bin": { "type": "string", "description": "Country determined according to the BIN of the card, country of the card's issuer (two-letter ISO code)." }, "currency_rate": { "type": "string", "description": "Currency exchange rate used for conversion of the payment amount from the source currency to the default currency." }, "customer_email": { "type": "string", "description": "Customer email address." }, "customer_id": { "type": "string", "description": "Identifier of the customer in the merchant's project." }, "eci": { "type": "string", "description": "Electronic commerce indicator. For possible values and more information, see [ECI codes](https://developers.ecommpay.com/en/en_ECI_codes.html)." }, "expiration_date": { "type": "string", "description": "Date indicating the validity period of the payment card." }, "legal_entity_name": { "type": "string", "description": "Name of the merchant's legal entity." }, "merchant_id": { "type": "string", "description": "Identifier of the merchant within the payment platform." }, "payment_currency": { "type": "string", "description": "Currency of the payment (currency in which payment_amount is specified). Must be the ISO 4217 alpha-3 currency code." }, "payment_type": { "type": "string", "description": "ID of the payment type. Possible values are: 3—Sale, 31—Purchase_dms, 6—Recurring, 24—Transfer, 11—Payout." }, "project_name": { "type": "string", "description": "Name of the merchant's website (project)." }, "project_url": { "type": "string", "description": "URL of the merchant's website (project)." }, "provider_payment_id": { "type": "string", "description": "Identifier of the operation assigned by the external payment system / provider." }, "recurring_id": { "type": "string", "description": "ID of debiting series received in the callback with the COF purchase registration data. This ID is used for all debits performed as part of the COF purchase." }, "recurring_register": { "type": "string", "description": "Specifies whether the recurring purchase was registered. Possible values are: 0—No. 1—Yes." }, "recurring_valid_thru": { "type": "string", "description": "Specifies the date until which the COF purchase is valid." }, "remaining_refund": { "type": "string", "description": "Reflects the remaining balance, only available for the operations which at certain point had success status." }, "secure_3ds_check": { "type": "string", "description": "Specifies whether the customer was redirected to the ACS (Access Control Service) page where the password from the text message is entered. Possible values are: 0—Was not redirected. 1—Was redirected." }, "transaction_completed_at": { "type": "string", "description": "Time of the payment completion." }, "transaction_created_at": { "type": "string", "description": "Time of the payment creation." }, "transaction_status": { "type": "string", "description": "Payment status." } }, "required": [ "project_id", "operation_id", "payment_id", "operation_type", "operation_status", "account_number", "customer_ip", "payment_method_name", "payment_method_type", "payment_description", "operation_created_at", "provider_date", "shipment_date", "sum_initial", "sum_converted", "arn", "rrn", "payment_provider_code", "payment_provider_message" ] } }, "consumes": [ "application/json" ], "produces": [ "application/json" ] } --- # Payment methods {#en_pm_about} A section with information about supported payment methods and the specifics of their work, including the overview with the classification of methods, method catalogue, and the description of each method. ## Overview {#section_cdx_r1q_yvb .section} The Ecommpay payment platform allows processing payments made with a variety of payment methods.Each payment method supports specific processing scenarios and operations in different regions. Thus, as a whole, combining a number of payment methods allows you to reach a diverse customer base all over the globe. Ecommpay is constantly expanding the range of supported payment methods and increasing the availability of payments made with the ever growing number of payment instruments and currencies in different regions.This section describesthe types of the supported payment methods, the individual methods, and the specifics of their use.It also covers [the testing options](en_pm_testing.md) for different operations performed with the use of various payment methods. If you have questions regarding the terms and conditions as well as the procedure of adding any of the supported payment methods, or if you would like to suggest a payment method \(or several\) for us to offer in the future, contact your Ecommpay account manager. If you have questions regarding the technical aspects of integrating, testing, or working with different methods, refer to the technical support specialists. - *Card payments or Cards*—payments that involve the transfer of funds between the accounts of the customer and the merchant with the use of the customer's payment card details.These payments can be processed via the Ecommpay processing centre \(in which case Ecommpay acts as an acquirer, thereby providing the services of *direct acquiring*\) and the systems of the partner-acquirers. The payment instrument in this case is always the payment card of the customer while the payment processing scenarios may differand may involve using specific services and performing various procedures.Payment methods of this type include standard card payments\(performed with the direct use of payment cards, without participation of additional services\) and such methods as Apple Pay, Click to Pay, and Google Pay that involve participation of eponymous servicesaimed at improving customer experience during card payments. **Note:** Within this documentation, the expression *card payments* refers to *standard card payments* unless otherwise noted. - *Bank payments or Banking*—payments that are carried out with the use of the specialised online services of different bankswhich allow transferring funds between the customer and the merchant \(directly or via the account of the provider\). The payment instrument in this case is the customer's bank account, while the payment processing scenarios may involve the online banking technologies, bank transfers, and other bank services.Payment methods of this type include the group of the European Open banking payment methods, online banking in South-East Asia \(for example, the Banks of Indonesia payment method\), and many others. - *Digital wallet payments or Wallets*—payments that involve the customer's digital walletprovided by a certain operator. The payment instruments in this case can vary: it can be the wallet itself \(for example, in case of such payment methods as PayPal andNeteller\) or the customer's payment card\(for example, in case of Apple Pay orGoogle Pay\), while the payment processing scenarios differ greatly depending on the intended use the wallet. - *QR code payments or QR codes*—payments that require the customer to scan a special QR codeand in certain cases perform other actions afterwards. The payment instrument in this case can be a bank account or a digital wallet.Payment methods of this type include Promptpay, QRIS and others. ## List of methods {#section_rsf_bbq_yvb .section} To find payment methods that fit your needs, use the following table with all supported methods. The data in the table can be sorted and filtered by various conditions. You can also use [Ecommpay shop](https://ecommpay.com/shop/) to find suitable methods by the type of your business and other criteria. | |Method|Type|Purchases|Payouts| |--|------|----|:-------:|:-----:| |![](images/pm/methods_icon/pm_card_payments.svg)|[Standard card payments](en_pm_card_payments.md)|card payments|+|+| |![](images/pm/methods_icon/pm_alipay.svg)|[Alipay](pm_alipay.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_applepay.svg)|[Apple Pay](pm_applepay.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_astropay.svg)|[AstroPay](pm_astropay.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_bancontact.svg)|[Bancontact](pm_bancontact.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_bancomatpay.svg)|[Bancomat Pay](pm_bancomatpay.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_hk_banks.svg)|[Banks of Hong Kong](pm_hk_banks.md#)|bank payments|–|+| |![](images/pm/methods_icon/pm_philippines.svg)|[Banks of the Philippines](pm_philippines.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_blik.svg)|[Blik](pm_blik.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_bnpl.svg)|[Buy Now Pay Later](pm_bnpl.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_boost.svg)|[Boost Wallet](pm_boost.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_brazil_ob.svg)|[Brazil Online Banking](pm_brazil_ob.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_bnpl.svg)|[Buy Now Pay Later](pm_bnpl.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_chile_ob.svg)|[Chile Online Banking](pm_chile_ob.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_unionpay.svg)|[China UnionPay](pm_unionpay.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_clicktopay.svg)|[Click to Pay](pm_clicktopay.md#)|card payments|+|–| |![](images/pm/methods_icon/pm_coinsph.svg)|[Coins.ph](pm_coinsph.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_dd_bacs.svg)|[Direct Debit BACS](pm_dd_bacs.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_dd_sepa.svg)|[Direct Debit SEPA](pm_dd_sepa.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_doku.svg)|[DOKU Wallet](pm_doku.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_ecuador_ob.svg)|[Ecuador Online Banking](pm_ecuador_ob.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_eps.svg)|[EPS](pm_eps.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_gcash.svg)|[GCash](pm_gcash.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_googlepay.svg)|[Google Pay](pm_googlepay.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_grabpay.svg)|[GrabPay](pm_grabpay.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_hk_qr.svg)|[Hong Kong FPS QR](pm_hk_qr.md#)|QR code payments|+|–| |![](images/pm/methods_icon/pm_ideal_wero.svg)|[iDEAL \| Wero](pm_ideal.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_indonesia.svg)|[Indonesian Online Banking](pm_indonesia.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_indonesia_va.svg)|[Indonesian Virtual Accounts](pm_indonesia_va.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_bankpayout_uk.svg)|[Local payouts to bank accounts in the UK](pm_bankpayout_uk.md#)|bank payments|–|+| |![](images/pm/methods_icon/pm_malaysia.svg)|[Malaysian Online Banking](pm_malaysia.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_maya.svg)|[Maya](pm_maya.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_mbway.svg)|[MBWay](pm_mbway.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_mexico_ob.svg)|[Mexico Online Banking](pm_mexico_ob.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_momoqr.svg)|[MoMo Wallet](pm_momoqr.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_multibanco.svg)|[Multibanco](pm_multibanco.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_mybank.svg)|[MyBank](pm_mybank.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_neteller.svg)|[Neteller](pm_neteller.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_austria.svg)|[Open Banking in Austria](pm_austria.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_belgium.svg)|[Open Banking in Belgium](pm_belgium.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_denmark.svg)|[Open Banking in Denmark](pm_denmark.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_estonia.svg)|[Open Banking in Estonia](pm_estonia.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_finland.svg)|[Open Banking in Finland](pm_finland.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_france.svg)|[Open Banking in France](pm_france.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_germany.svg)|[Open Banking in Germany](pm_germany.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_hungary.svg)|[Open Banking in Hungary](pm_hungary.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_italy.svg)|[Open Banking in Italy](pm_italy.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_ireland.svg)|[Open Banking in Ireland](pm_ireland.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_latvia.svg)|[Open Banking in Latvia](pm_latvia.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_lithuania.svg)|[Open Banking in Lithuania](pm_lithuania.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_luxembourg.svg)|[Open Banking in Luxembourg](pm_luxembourg.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_norway.svg)|[Open Banking in Norway](pm_norway.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_poland.svg)|[Open Banking in Poland](pm_poland.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_portugal.svg)|[Open Banking in Portugal](pm_portugal.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_romania.svg)|[Open Banking in Romania](pm_romania.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_spain.svg)|[Open Banking in Spain](pm_spain.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_sweden.svg)|[Open Banking in Sweden](pm_sweden.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_netherlands.svg)|[Open Banking in the Netherlands](pm_netherlands.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_uk.svg)|[Open Banking in the UK](pm_uk.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_ovo.svg)|[OVO Wallet](pm_ovo.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_bankpayout_sepa.svg)|[Payouts to bank accounts in SEPA](pm_bankpayout_sepa.md#)|bank payments|–|+| |![](images/pm/methods_icon/pm_paypal.svg)|[PayPal](pm_paypal.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_paypal_pay_later.svg)|[PayPal Pay Later](pm_paypal_pay_later.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_peru_ob.svg)|[Peru Online Banking](pm_peru_ob.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_philippines_atm.svg)|[Philippines Over the Counter & ATM](pm_philippines_atm.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_pix.svg)|[PIX](pm_pix.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_promptpay.svg)|[Promptpay](pm_promptpay.md#)|QR code payments|+|–| |![](images/pm/methods_icon/pm_przelewy.svg)|[Przelewy24](pm_przelewy.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_satispay.svg)|[Satispay](pm_satispay.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_qris.svg)|[QRIS](pm_qris.md#)|QR code payments|+|–| |![](images/pm/methods_icon/pm_qrph.svg)|[QR Ph](pm_qrph.md#)|QR code payments|+|–| |![](images/pm/methods_icon/pm_shopee.svg)|[Shopee](pm_shopee.md#)|digital wallet payments|+|−| |![](images/pm/methods_icon/pm_skrill.svg)|[Skrill Wallet](pm_skrill.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_swish.svg)|[Swish](pm_swish.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_thailand.svg)|[Thai Online Banking](pm_thailand.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_touchngo.svg)|[Touch&Go](pm_touchngo.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_truemoney.svg)|[TrueMoney](pm_truemoney.md#)|QR code payments|+|–| |![](images/pm/methods_icon/pm_twint.svg)|[TWINT](pm_twint.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_vietnam.svg)|[Vietnamese Online Banking](pm_vietnam.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_instalments.svg)|[Visa Instalments](pm_instalments.md#)|card payments|+|–| |![](images/pm/methods_icon/pm_wechat.svg)|[WeChat](pm_wechat.md#)|digital wallet payments|+|–| - **[Card payments](en_pm_cardpayments.md)** Articles about card payments that involve the transfer of funds with the use of the customer's payment card details. - **[Bank payments](en_pm_bankpayments.md)** Articles about bank payments that involve the transfer of funds with the use of the specialised online services of different banks. - **[Digital wallet payments](en_pm_ewallet.md)** Articles about digital wallets that involve the transfer of funds with the use of the customer's digital wallet provided by a specific operator. - **[QR code payments](en_pm_qr.md)** Articles about QR code payments that require the customer to scan a special QR code in order to transfer the funds. - **[Testing](en_pm_testing.md)** An article about the capability of testing different types of payments and operations for different payment methods. --- # Card payments {#en_pm_cardpayments} Articles about card payments that involve the transfer of funds with the use of the customer's payment card details. *Card payments or Cards*—payments that involve the transfer of funds between the accounts of the customer and the merchant with the use of the customer's payment card details.These payments can be processed via the Ecommpay processing centre \(in which case Ecommpay acts as an acquirer, thereby providing the services of *direct acquiring*\) and the systems of the partner-acquirers. The payment instrument in this case is always the payment card of the customer while the payment processing scenarios may differand may involve using specific services and performing various procedures. Payment methods of this type include [standard card payments](en_pm_card_payments.md), as well as the functionality of paying in [instalments enabled by Visa](pm_instalments.md#),and such methods as [Apple Pay](pm_applepay.md#), [Click to Pay](pm_clicktopay.md#), and [Google Pay](pm_googlepay.md#). - **[Standard card payments](en_pm_card_payments.md)** An article about the payment method which allows you to process payments made with the direct use of payment cards in most regions and supports purchases \(as well as instalments\), refunds, and payouts. - **[Click to Pay](pm_clicktopay.md#)** - **[Visa Instalments](pm_instalments.md#)** **Parent topic:**[Payment methods](en_pm_about.md) --- # Standard card payments {#en_pm_card_payments} An article about the payment method which allows you to process payments made with the direct use of payment cards in most regions and supports purchases \(as well as instalments\), refunds, and payouts. *Card payments* is a payment method which allows to process payments made with the direct use of payment cards in most regions.This method supports purchases\(as well as [instalments](pm_instalments.md#)\), refunds and payouts. This payment method supports the following: |Payment method type|card payments| |Payment instruments|payments cards| |Countries and regions|most countries in the world| |Payment currencies|most currencies in the world| |Currency conversion|+| |Purchases|+| |Payouts|+| |Stored credentials payments|+| |Full refunds|+| |Partial refunds|+| |Chargebacks|+| |Notes|+| |Onboarding and access fee|refer to your Ecommpay account manager| Information about the actions required to process payments by using different interfaces is presented in the sections [Gate](en_Gate_Integration_About.md#section_y53_dsc_stb), [Payment Page](en_PP_about.md#section_ywk_z5g_btb), and [Dashboard](en_dbl_payments.md#). **Parent topic:**[Card payments](en_pm_cardpayments.md) --- # Bank payments {#en_pm_bankpayments} Articles about bank payments that involve the transfer of funds with the use of the specialised online services of different banks. *Bank payments or Banking*—payments that are carried out with the use of the specialised online services of different bankswhich allow transferring funds between the customer and the merchant \(directly or via the account of the provider\). The payment instrument in this case is the customer's bank account, while the payment processing scenarios may involve the online banking technologies, bank transfers, and other bank services. Payment methods of this type include: - [Bancontact](pm_bancontact.md#) - Banks of South-East Asia: - [Banks of Hong Kong](pm_hk_banks.md#) - [Banks of the Philippines](pm_philippines.md#) - [Indonesian Online Banking](pm_indonesia.md#) - [Malaysian Online Banking](pm_malaysia.md#) - [Singapore Online Banking](pm_singapore.md) - [Thai Online Banking](pm_thailand.md#) - [Vietnamese Online Banking](pm_vietnam.md#) - [Blik](pm_blik.md#) - [Brazil Online Banking](pm_brazil_ob.md#) - [Buy Now Pay Later](pm_bnpl.md#) - [Chile Online Banking](pm_chile_ob.md#) - [China UnionPay](pm_unionpay.md#) - [Direct Debit BACS](pm_dd_bacs.md#) - [Direct Debit SEPA](pm_dd_sepa.md#) - [Ecuador Online Banking](pm_ecuador_ob.md#) - [EPS](pm_eps.md#) - European Open Banking\([methods group](pm_openbanking.md#)\): | - [Austria](pm_austria.md#) - [Belgium](pm_belgium.md#) - [Estonia](pm_estonia.md#) - [Finland](pm_finland.md#) - [France](pm_france.md#) - [Germany](pm_germany.md#) - [Hungary](pm_hungary.md#) - [Italy](pm_italy.md#) - [Ireland](pm_ireland.md#) - [Latvia](pm_latvia.md#) | - [Lithuania](pm_lithuania.md#) - [Netherlands](pm_netherlands.md#) - [Norway](pm_norway.md#) - [Poland](pm_poland.md#) - [Portugal](pm_portugal.md#) - [Romania](pm_romania.md#) - [Spain](pm_spain.md#) - [Sweden](pm_sweden.md#) - [United Kingdom](pm_uk.md#) | | | - [iDEAL \| Wero](pm_ideal.md#) - [Indonesian Virtual Accounts](pm_indonesia_va.md#) - [Local payouts to bank accounts in the UK](pm_bankpayout_uk.md#) - [Mexico Online Banking](pm_mexico_ob.md#) - [Multibanco](pm_multibanco.md#) - [MyBank](pm_mybank.md#) - [Payouts to bank accounts in SEPA](pm_bankpayout_sepa.md#) - [Peru Online Banking](pm_peru_ob.md#) - [Philippines Over the Counter & ATM](pm_philippines_atm.md#) - [PIX](pm_pix.md#) - [Przelewy24](pm_przelewy.md#) - [Swish](pm_swish.md#) - **[Bancontact](pm_bancontact.md#)** - **[Banks of Hong Kong](pm_hk_banks.md#)** - **[Banks of the Philippines](pm_philippines.md#)** - **[Blik](pm_blik.md#)** - **[Brazil Online Banking](pm_brazil_ob.md#)** - **[Buy Now Pay Later](pm_bnpl.md#)** - **[Chile Online Banking](pm_chile_ob.md#)** - **[China UnionPay](pm_unionpay.md#)** - **[Direct Debit BACS](pm_dd_bacs.md#)** - **[Direct Debit SEPA](pm_dd_sepa.md#)** - **[Ecuador Online Banking](pm_ecuador_ob.md#)** - **[EPS](pm_eps.md#)** - **[iDEAL \| Wero](pm_ideal.md#)** - **[Indonesian Online Banking](pm_indonesia.md#)** - **[Indonesian Virtual Accounts](pm_indonesia_va.md#)** - **[Local payouts to bank accounts in the UK](pm_bankpayout_uk.md#)** - **[Malaysian Online Banking](pm_malaysia.md#)** - **[Mexico Online Banking](pm_mexico_ob.md#)** - **[Multibanco](pm_multibanco.md#)** - **[MyBank](pm_mybank.md#)** - **[Open Banking \(methods group\)](pm_openbanking.md#)** - **[Open Banking in Austria](pm_austria.md#)** - **[Open Banking in Belgium](pm_belgium.md#)** - **[Open Banking in Denmark](pm_denmark.md#)** - **[Open Banking in Estonia](pm_estonia.md#)** - **[Open Banking in Finland](pm_finland.md#)** - **[Open Banking in France](pm_france.md#)** - **[Open Banking in Germany](pm_germany.md#)** - **[Open Banking in Hungary](pm_hungary.md#)** - **[Open Banking in Italy](pm_italy.md#)** - **[Open Banking in Ireland](pm_ireland.md#)** - **[Open Banking in Latvia](pm_latvia.md#)** - **[Open Banking in Lithuania](pm_lithuania.md#)** - **[Open Banking in Luxembourg](pm_luxembourg.md#)** - **[Open Banking in the Netherlands](pm_netherlands.md#)** - **[Open Banking in Norway](pm_norway.md#)** - **[Open Banking in Poland](pm_poland.md#)** - **[Open Banking in Portugal](pm_portugal.md#)** - **[Open Banking in Romania](pm_romania.md#)** - **[Open Banking in Spain](pm_spain.md#)** - **[Open Banking in Sweden](pm_sweden.md#)** - **[Open Banking in the UK](pm_uk.md#)** - **[Payouts to bank accounts in SEPA](pm_bankpayout_sepa.md#)** - **[Peru Online Banking](pm_peru_ob.md#)** - **[Philippines Over the Counter & ATM](pm_philippines_atm.md#)** - **[PIX](pm_pix.md#)** - **[Przelewy24](pm_przelewy.md#)** - **[Swish](pm_swish.md#)** - **[Thai Online Banking](pm_thailand.md#)** - **[Vietnamese Online Banking](pm_vietnam.md#)** **Parent topic:**[Payment methods](en_pm_about.md) --- # Digital wallet payments {#en_pm_ewallet} Articles about digital wallets that involve the transfer of funds with the use of the customer's digital wallet provided by a specific operator. *Digital wallet payments or Wallets*—payments that involve the customer's digital walletprovided by a certain operator. The payment instruments in this case can vary: it can be the wallet itself \(for example, in case of such payment methods as PayPal andNeteller\) or the customer's payment card\(for example, in case of Apple Pay orGoogle Pay\), while the payment processing scenarios differ greatly depending on the intended use the wallet. Payment methods of this type include: - [Alipay](pm_alipay.md#) - [Apple Pay](pm_applepay.md#) - [AstroPay](pm_astropay.md#) - [Bancomat Pay](pm_bancomatpay.md#) - [Boost Wallet](pm_boost.md#) - [Coins.ph](pm_coinsph.md#) - [DOKU Wallet](pm_doku.md#) - [GCash](pm_gcash.md#) - [Google Pay](pm_googlepay.md#) - [GrabPay](pm_grabpay.md#) - [Maya](pm_maya.md#) - [MBWay](pm_mbway.md#) - [MoMo Wallet](pm_momoqr.md#) - [Neteller](pm_neteller.md#) - [OVO Wallet](pm_ovo.md#) - [PayPal](pm_paypal.md#) - [PayPal Pay Later](pm_paypal_pay_later.md#) - [Satispay](pm_satispay.md#) - [Shopee](pm_shopee.md#) - [Skrill Wallet](pm_skrill.md#) - [Touch&Go](pm_touchngo.md#) - [TWINT](pm_twint.md#) - [WeChat](pm_wechat.md#) - **[Alipay](pm_alipay.md#)** - **[Apple Pay](pm_applepay.md#)** - **[AstroPay](pm_astropay.md#)** - **[Bancomat Pay](pm_bancomatpay.md#)** - **[Boost Wallet](pm_boost.md#)** - **[Coins.ph](pm_coinsph.md#)** - **[DOKU Wallet](pm_doku.md#)** - **[GCash](pm_gcash.md#)** - **[Google Pay](pm_googlepay.md#)** - **[GrabPay](pm_grabpay.md#)** - **[Maya](pm_maya.md#)** - **[MBWay](pm_mbway.md#)** - **[MoMo Wallet](pm_momoqr.md#)** - **[Neteller](pm_neteller.md#)** - **[OVO Wallet](pm_ovo.md#)** - **[Paypal](pm_paypal.md#)** - **[PayPal Pay Later](pm_paypal_pay_later.md#)** - **[Satispay](pm_satispay.md#)** - **[Shopee](pm_shopee.md#)** - **[Skrill Wallet](pm_skrill.md#)** - **[Touch&Go](pm_touchngo.md#)** - **[TWINT](pm_twint.md#)** - **[WeChat](pm_wechat.md#)** **Parent topic:**[Payment methods](en_pm_about.md) --- # QR code payments {#en_pm_qr} Articles about QR code payments that require the customer to scan a special QR code in order to transfer the funds. *QR code payments or QR codes*—payments that require the customer to scan a special QR codeand in certain cases perform other actions afterwards. The payment instrument in this case can be a bank account or a digital wallet. Payment methods of this type include: - [Hong Kong FPS QR](pm_hk_qr.md#) - [Promptpay](pm_promptpay.md#) - [QRIS](pm_qris.md#) - [QR Ph](pm_qrph.md#) - [TrueMoney](pm_truemoney.md#) - **[Hong Kong FPS QR](pm_hk_qr.md#)** - **[Promptpay](pm_promptpay.md#)** - **[QRIS](pm_qris.md#)** - **[QR Ph](pm_qrph.md#)** - **[TrueMoney](pm_truemoney.md#)** **Parent topic:**[Payment methods](en_pm_about.md) --- # Testing {#en_pm_testing} An article about the capability of testing different types of payments and operations for different payment methods. Testing is one of the crucial steps of integrating new payment methods: it is important to test both the user scenarios and the correctness of the technical integration. To facilitate this process, the Ecommpay payment platform supports emulators of different payment systems and payment operations, and the work on developing and improving these emulators is always ongoing.At the moment, the emulators allow you to test the following payments and operations: |Method|Purchases|Refunds|Payouts| |------|:-------:|:-----:|:-----:| |[Alipay](pm_alipay.md#)|+|+|–| |[Apple Pay](pm_applepay.md#)|+|–|–| |[Indonesian Online Banking](pm_indonesia.md#)|+|–|+| |[Vietnamese Online Banking](pm_vietnam.md#)|+|–|+| |[Malaysian Online Banking](pm_malaysia.md#)|+|–|+| |[Thai Online Banking](pm_thailand.md#)|+|–|+| |[DOKU Wallet](pm_doku.md#)|+|–|+| |[Google Pay](pm_googlepay.md#)|+|–|–| |[Neteller](pm_neteller.md#)|+|–|+| |[Skrill Wallet](pm_skrill.md#)|+|+|+| For more information on testing the payments and operations listed above, refer to the articles about the corresponding methods. For more information on testing card payments, see articles in the [Test cards](en_test_cards.md) section. Additional questions should be addressed to Ecommpay technical support. **Parent topic:**[Payment methods](en_pm_about.md) --- # B2B Remittances {#en_b2bremit_about} A section about processing payments to corporate accounts of the merchant's suppliers and other partner companies. This section covers the information on B2B remittances—payments to corporate accounts of the merchant's partners. It is a business payment solution that helps merchants to pay their suppliers and other companies and facilitates a well-rounded approach to payment processing. - [Overview](en_b2bremit_overview.md#)describes the purpose and the workflow of B2B remittances solution. - [B2B remittances via Dashboard](en_b2bremit_db.md)describes how to work with accounts of remittance recipients and how to make B2B payments to corporate partners via Dashboard. - [B2B remittances via the Gate API](en_b2bremit_api.md)describes how to work with accounts of remittance recipients and how to make B2B payments to corporate partners via the Gate API. - **[Overview](en_b2bremit_overview.md#)** An article with the introductory information about B2B payments and the general description of working with remittance accounts and remittance payments. - **[B2B remittances via Dashboard](en_b2bremit_db.md)** An article about working with accounts of remittance recipients and making B2B payments to corporate partners via Dashboard. - **[B2B remittances via the Gate API](en_b2bremit_api.md)** An article about working with accounts of remittance recipients and making B2B payments to corporate partners via the the Gate API. - **[B2B API](b2b_api.md)** The B2B API specification with the descriptions of data structures and schemas for generating requests to different endpoints. --- # B2B remittances via Dashboard {#en_b2bremit_db} An article about working with accounts of remittance recipients and making B2B payments to corporate partners via Dashboard. ## Overview {#section_mlx_1dy_dtb .section} Dashboard allows users to create and manage accounts of the remittance recipients, create single and mass remittance orders and monitor the data on all payments, both completed and in-progress. In each case, the following requirements must be met: - Two-factor authentication is required for accessing Dashboard in order to create remittance orders or to send recipient accounts for approval. - The user account must be granted the appropriate permissions. The full set of permissions for working with the B2B remittances is granted to the user accounts with the assigned Operations and Merchant Admin roles.User accounts with the assigned Finance and Support roles can only view the information in the **Remittances** section. To learn more about how to access this section in the Dashboard interface, see [Core capabilities and role-based access model](en_dbl_roles_overview.md#). In the **Remittances** section you can access the information about all created recipient accounts in the **Remittances Recipient Account Details** list and the information about all remittance payments to partners in the **All Remittances** list and the payment information tabs. You can also monitor information about the remittance payments made using a batch request in the **Mass Remittances Requests** registry. ## Creating and editing a remittance recipient account {#section_jf1_d2y_dtb .section} To create a recipient account, you should: 1. Open the **New recipient account** panel. To achieve this, switch to the list of the remittance recipient accounts and click **Create Recipient Account**. 2. Specify the information about the partner company that you will send payments to. To achieve this, fill in the fields in the following tabs: **General information**, **Recipient**, **Company address**, and **Remittances details**. When filling in the fields, keep in mind that: - With the exception of three optional fields \(recipient's bank address and country and the company's postal code\), all other fields are required. - If any of the required fields is left blank or filled incorrectly, you will not be able to save the account as a draft or send it for approval. In this case, if you click **Save as Draft**, these fields will be marked in red with the suggestion as to what information is expected in each of them. The button **Send for approval** will be disabled as well. In addition, the tabs where required information is missing will be marked with the ![](images/universal/dbl/icon_error_field.svg) icon, while the tabs that were filled in correctly will be marked with the ![](images/universal/dbl/icon_complete.svg) icon. - If you save the recipient account as a draft, you can continue working on it later. The draft can be edited for thirty days. If necessary, the account with the **Draft** status can be deleted by clicking the ![](images/universal/dbl/icon_trashbin.svg) button in the row of this account in the list. 3. Send the account for approval to Ecommpay. The button **Send for approval** is enabled if all required fields are filled in correctly. Once you click this button, the recipient account is marked as **Created** in the list and can no longer be edited. ![](images/ecommpay/dbl/en_dbl_newaccount_generalinfo.svg "New recipient account panel") ![](images/ecommpay/dbl/en_dbl_newaccount_incomplete.svg "Example of blank fields in the form") ![](images/ecommpay/dbl/en_dbl_newaccount_saveasdraft.svg "Saving the account as a draft") ![](images/ecommpay/dbl/en_dbl_newaccount_sendforapproval.svg "Sending the account for approval") ## Deleting the remittance recipient account {#section_nd1_mfy_dtb .section} To delete the recipient account, you should: 1. If necessary, locate the account you need to delete by going to the **Remittances Recipient Account Details** list and applying necessary filters. 2. Delete the account by using the ![](images/universal/dbl/icon_trashbin.svg) button in the corresponding row of the list. Keep in mind that you cannot delete the account with the **Created** status. Hence, the deletion button is disabled for such accounts in the list. 3. Confirm deleting the account in the popup window. ## Creating a single remittance order {#section_zsr_wfy_dtb .section} To create a B2B remittance order, you should: 1. Open the **New remittance** panel. To achieve this, go to **Remittances**, click **Create remittance** on the left of the filtering panel, and switch to the **Single Remittance** tab. 2. Specify the remittance order parameters and send the request. To achieve this, fill in the fields and click **Send request**. If needed, confirm by entering the SMS verification code in the popup window. When filling in the fields, keep in mind that: - When you select the **Recipient Account ID**, the dropdown list will only contain accounts with the **Active** status. The remittance order can be created only for the recipient whose account has been approved and is not expired. - The **Currency** field is read only because its value is always the currency specified in the recipient account. - The **Description** field is optional. - The **Send request** button is enabled when all required parameters are specified correctly. ![](images/ecommpay/dbl/en_dbl_sendremit_request.svg "Example of a completed remittance order with the enabled button.") 3. Make sure that the payment has been processed. You can do this by checking the status of this payment in the **All Remittances** list—it should state `success`. ## Creating a mass remittance order {#section_p5z_bhz_55b .section} To make a series of B2B payments using a batch request: 1. Create and prepare a file with the remittance payments data in the specified format. Keep in mind that the remittances order can be created only for the recipients whose accounts have been approved and are not expired. Thus, when you specify the identifiers of the recipient accounts, make sure that the target recipient accounts have the **Active** status. The template of the file is available for download on Dashboard, while the file requirements can be found [here](en_dbl_payments.md#). 2. Go to the **Mass Remittances** tab of the **New remittance** panel. To achieve this, go to **Remittances**, click **Create remittance** on the left of the filtering panel, and switch to the **Mass Remittances** tab. 3. Upload the file with the list of remittance payments and send the batch request. Drag the file or use the **Browse to upload** link. After the file has been uploaded, make sure the **Send request** button is enabled. Use this button to send the batch request; if needed, enter the SMS verification code in the popup window. ![](images/ecommpay/dbl/en_dbl_mass_remittances.svg) If the file is incorrect, the **Send request** button remains inactive and the error message is shown. In this case, view the error details \(using the preview toggle switch and then the **File details** button\), correct the errors, and re-upload the file. 4. Make sure the batch request for mass remittances has been processed. After the batch request has been sent and you can see the notification that it has been accepted, it is important to check that the remittance payments have been processed. Look up the batch status in the list of mass requests—the status should state `Done`. Keep in mind that the time it takes to process remittance payments and to update their status information can significantly vary depending on the number of payments in the batch and the specified payment amounts. You can also monitor status information of remittance payments in the batch using the column Indicator in the list of mass requests. **Parent topic:**[B2B Remittances](en_b2bremit_about.md) --- # B2B remittances via the Gate API {#en_b2bremit_api} An article about working with accounts of remittance recipients and making B2B payments to corporate partners via the the Gate API. ## Overview {#section_dhv_vgy_dtb .section} The following endpoints in the Gate API are used to make B2B payments to partners: - [/v2/recipient-account/list](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-list)—to retrieve information about remittance recipient accounts - [/v2/recipient-account/create](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-create)—to create an account of the remittance recipient - [/v2/recipient-account/update](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-update)—to modify information specified in the recipient account draft - [/v2/recipient-account/send-for-approval](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-send-for-approval)—to send the recipient account for approval to Ecommpay - [/v2/recipient-account/delete](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-delete)—to delete the recipient account - [/v2/payment/remittance/external](https://api-developers.ecommpay.com/remittances/post-v2-payment-remittance-external)—to send the remittance request. The `recipient-account` requests are synchronous while the `remittance` requests are asynchronous. To learn more about these interaction models, see [Interaction concepts](en_pp_interaction_organisation.md#). To learn more about using signatures, see [Signature generation and verification](en_platform_signature.md#). This section covers special aspects of sending requests to the B2B remittances endpoints. ## Retrieving recipient account data {#section_rfv_mhy_dtb .section} Requests to retrieve recipient account data should be sent to the [/v2/recipient-account/list](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-list) endpoint. These requests must contain parameters `project_id` \(project ID assigned at the stage of integration\) and `signature`. Responses to such requests contain the information about all recipient accounts structured according to the [RecipientAccount](https://api-developers.ecommpay.com/api.html#/c2NoOjUxMTkxMjY1-recipient-account) model. To filter recipient account data by recipient account IDs, assigned statuses, or currency, use the `id`, `status`, and `currency` arrays. By default, if the request does not contain these arrays, the payment platform returns data for all recipient accounts. Specify recipient account IDs for the accounts you need information on and the status types and currencies in the `id`, `status` and `currency` arrays if you need to pass several values. Separate multiple elements within the arrays by a comma with a space if necessary. If you need to pass a single value, use the `id`, `status`, and `currency` strings. ``` // Request body { "project_id": 21261, "signature": "UGVhY2UgdG8gdGhlIHdvcmxkIA==" } // Response body [ { "general": { "project_id": 21261 }, "info": { "id": 3, "title": "Galaxy catering", "status": "expired", "exp_date": "2021-10-31", "created_date": "2021-09-27 15:24:00", "updated_date": "2021-09-27 15:24:00" }, "recipient_info": { "beneficiary_account": "1242424225621221", "currency": "GBP", "remittance_description": "Catering Pluto locations", "beneficiary_name": "Grebulon", "beneficiary_bank_name": "Taurus bank", "beneficiary_bank_code": "3244232", "beneficiary_bank_country": "PL", "recipient_bank_address": "Tombaugh Regio, Astrid colles, 457" }, "remittance_details": { "monthly_min_amount": 22000, "transfer_max_amount": 2000, "remittance_velocity": 10, "during_days": 30 }, "payment_methods": [ "bank-transfer/world" ], "company_info": { "legal_address": "Rupert", "legal_country": "RP", "legal_city": "Rupert", "zip_code": "101010" } }, { "general": { "project_id": 21261 }, "info": { "id": 7, "title": "Galaxy catering", "status": "created", "exp_date": "0000-00-00", "created_date": "2021-09-01 10:58:36", "updated_date": "2021-09-01 10:58:36" }, "recipient_info": { "beneficiary_account": "1242424225621221", "currency": "EUR", "remittance_description": "Catering Rupert locations", "beneficiary_name": "Grebulon", "beneficiary_bank_name": "Random bank", "beneficiary_bank_code": "13243532", "beneficiary_bank_country": "RP", "recipient_bank_address": "Lila ice plain, 324" }, "remittance_details": { "monthly_min_amount": 2099, "transfer_max_amount": 3099, "remittance_velocity": 30, "during_days": 30 }, "payment_methods": [ "bank-transfer/world" ], "company_info": { "legal_address": "Rupert", "legal_country": "RP", "legal_city": "Rupert" } } ] ``` ## Creating a remittance recipient account {#section_fwq_23y_dtb .section} Requests to create a recipient account should be sent to the [/v2/recipient-account/create](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-create) endpoint. These requests must contain parameters `project_id` and `signature` in the `general` object and the `title` parameter \(the name of the new account\) in the `info` object. In addition, the requests can contain any other significant information about the remittance recipient\(information about the company, payment details and other financial data required to make a B2B payment to the corporate account\). Each response to such requests contains the ID of the created recipient account in the `info` object. ``` // Request body { "general": { "project_id": 21261, "signature": "UGVhY2UgdG8gdGhlIHdvcmxkIA==" }, "info": { "title": "Galaxy catering" }, "recipient_info": { "beneficiary_account": "1242424225621221", "currency": "EUR", "remittance_description": "Catering Rupert locations", "beneficiary_name": "Grebulon", "beneficiary_bank_name": "Random bank", "beneficiary_bank_code": "13243532" }, "remittance_details": { "monthly_min_amount": 2099, "transfer_max_amount": 3099, "remittance_velocity": 30, "during_days": 30 }, "company_info": { "legal_address": "Rupert", "legal_country": "RP", "legal_city": "Rupert" } } // Response body { "info": { "id": 7 } } ``` ## Modifying information specified in the recipient account draft {#section_jfm_43y_dtb .section} Requests to update a recipient account should be sent to the [/v2/recipient-account/update](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-update) endpoint. These requests must contain parameters `project_id` and `signature` in the `general` object and the `id` parameter \(the recipient account ID assigned when the account was created\) in the `info` object. In addition, the requests must contain the information about the remittance recipient\(information about the company, payment details and other financial data required to make a B2B payment to the corporate account\) that needs to be modified. Updating the recipient account triggers a `200 OK` response. ``` { "general": { "project_id": 21261, "signature": "UGVhY2UgdG8gdGhlIHdvcmxkIA==" }, "info": { "id": 7, "title": "Galaxy catering new" } } ``` ## Sending the recipient account for approval {#section_ohm_h1p_3tb .section} Requests to send the recipient account for approval should be sent to the [/v2/recipient-account/send-for-approval](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-send-for-approval) endpoint. These requests must contain parameters `project_id` and `signature` in the `general` object and the `id` parameter in the `info` object. Only those accounts for which you have provided all necessary data should be sent for approval. Keep in mind that the currency of the payment and the country of the recipient must be specified in the relevant formats \(see [References](en_directory.md)\). - The `info` object must contain the `title` parameter that specifies the name of the recipient account. - The `recipient_info` object must contain the following parameters: - `beneficiary_account`—account number of the remittance recipient company - `currency`—code of the currency used for making B2B payments \(in the ISO-4217 alpha-3 format\) - `remittance_description`—purpose of payment description - `beneficiary_name`—name of the remittance recipient company - `beneficiary_bank_name`—name of the bank that holds the account of the remittance recipient company - `beneficiary_bank_code`—code of the bank that holds the account of the remittance recipient company - The `remittance_details` object must contain the following parameters: - `monthly_min_amount`—minimum amount of payments over a month - `transfer_max_amount`—maximum amount of a single payment - `remittance_velocity`—expected number of payments over 30 days **Note:** If the specified maximum amount of a single payment and the expected number of payments over 30 days are significantly exceeded, processing the remittance order may take up to 14 business days. To avoid the procedure of additional approval by the Ecommpay specialists, allow some leeway when specifying the values for these parameters. - The `company_info` object must contain the following parameters: - `legal_address`—legal address of the remittance recipient company - `legal_country`—code of the country where the remittance recipient company is registered \(in the ISO 3166-1 alpha-2 format\) - `legal_city`—name of the city where the remittance recipient company is registered A valid `send-for-approval` request with correct information triggers a `200 OK` response. If the information about the recipient account is incomplete, the response to such request contains the `errors` array with the list of parameters that are missing. If the information about the recipient account is incorrect, the response to such request contains the `errors` array specifying the data that requires correction. In this case, you should specify the required information using the [/v2/recipient-account/update](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-update) request and then repeat sending the recipient account for approval.If you need to look up the definitions of the received response codes, see [Handling operation processing information](en_platform_payment_info_codes.md). ``` { "general": { "project_id": 21261, "signature": "UGVhY2UgdG8gdGhlIHdvcmxkIA==" }, "info": { "id": 7 } } ``` ``` HTTP/1.1 400 Bad Request //response status line ... //header fields { "status":"error", //request processing status "errors":[ //array with the list of the missing required parameters { "code":"2003", "message":"Must be at least 4 characters long", "field":"recipient_info.beneficiary_account", "constraint":"" }, { "code":"2003", "message":"Must have a minimum value of 1", "field":"remittance_details.monthly_min_amount", "constraint":"" } ] } ``` ``` HTTP/1.1 400 Bad Request //response status line ... //header fields { "status":"error", //request processing status "errors":[ //information about parameters that require correction { "code":"2003", "message":"Invalid value for field recipient_info.currency", "field":"recipient_info.currency", "constraint":"" } ] } ``` ## Deleting the remittance recipient account {#section_dv2_1jy_dtb .section} Requests to delete a recipient account should be sent to the [/v2/recipient-account/delete](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-delete) endpoint. These requests must contain parameters `project_id` and `signature` in the `general` object and the `id` parameter in the `info` object. Deleting the recipient account triggers a `200 OK` response. ``` { "general": { "project_id": 21261, "signature": "UGVhY2UgdG8gdGhlIHdvcmxkIA==" }, "info": { "id": 7 } } ``` ## Sending the remittance request {#section_zkk_njy_dtb .section} Requests to create a remittance order should be sent to the [/v2/payment/remittance/external](https://api-developers.ecommpay.com/remittances/post-v2-payment-remittance-external) endpoint. Keep in mind that remittance orders can be created only for approved recipient accounts that are not expired\(and these accounts are assigned the **Active** status\). These requests must contain the following parameters: - `id` \(the recipient account ID assigned when the account was created\) in the `recipient` object. - `project_id`, `payment_id`, and `signature` in the `general` object. - `amount`, `currency`, and `payment_method_alias` \(the payment amount, currency, and the ID of the payment method that is sourced from the `payment_methods` array sent in the response to the [/v2/recipient-account/list](https://api-developers.ecommpay.com/remittances/post-v2-recipient-account-list) request\) in the `payment` object. ``` { "general": { "project_id": 21261, "payment_id": "galaxy_catering_0001", "signature": "UGVhY2UgdG8gdGhlIHdvcmxkIA==" }, "payment": { "amount": 234, "currency": "EUR", "payment_method_alias": "bank-transfer/world", "description": "Catering Mars locations" }, "recipient": { "id": 7 } } ``` To communicate the remittance payment results, standard callbacks are used. To learn more, see [Handling callbacks](en_platform_callbacks.md#). **Parent topic:**[B2B Remittances](en_b2bremit_about.md) --- # B2B API {#b2b_api} **Up one level:** [B2B Remittances](en_b2bremit_about.md) { "openapi": "3.0.2", "info": { "title": "Remittances", "description": "Requests for making B2B payments and working with recipient accounts", "version": "3.34.5" }, "servers": [ { "url": "https://api.ecommpay.com" } ], "paths": { "/v2/payment/remittance/external": { "post": { "summary": "/v2/payment/remittance/external", "description": "Request to send money from merchant to legal entities (merchant partners)", "operationId": "POST_v2-payment-remittance-external", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "payment", "recipient" ], "type": "object", "properties": { "general": { "$ref": "#/components/schemas/GeneralInfo" }, "payment": { "type": "object", "description": "Object that contains payment information", "required": [ "amount", "currency", "payment_method_alias" ], "properties": { "amount": { "type": "integer", "minimum": 1, "maximum": 10000000000000, "description": "Payment amount in minor units of currency" }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Payment currency in the ISO 4217 alpha-3 format" }, "payment_method_alias": { "type": "string", "description": "Alias of payment method" }, "description": { "type": "string", "maxLength": 255, "description": "Payment description or comment for additional data analisys by using Dashboard" } } }, "recipient": { "type": "object", "description": "Object that contains the data of the recipient", "required": [ "id" ], "properties": { "id": { "type": "integer", "description": "Identifier of recipient account card" } } }, "interface_type": { "$ref": "#/components/schemas/SourceInfo" } } } } }, "required": true }, "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/GateSuccessResponse" } } } }, "400": { "description": "Data validation error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid data structure or JSON parsing error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } } } }, "/v2/recipient-account/list": { "post": { "summary": "/v2/recipient-account/list", "operationId": "POST_v2-recipient-account-list", "requestBody": { "content": { "application/json": { "schema": { "required": [ "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "minimum": 1, "maximum": 4294967295 }, "currency": { "anyOf": [ { "type": "array", "items": { "type": "string", "pattern": "^[A-Z]{3}$" }, "description": "Array of currencies in the ISO 4217 alpha-3 format" }, { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Currency in the ISO 4217 alpha-3 format" } ] }, "status": { "anyOf": [ { "type": "array", "items": { "type": "string" }, "description": "Array of statuses of recipient account entity" }, { "type": "string", "description": "Status of recipient account entity" } ] }, "id": { "anyOf": [ { "type": "array", "items": { "type": "integer", "minimum": 1 }, "description": "Array of ID" }, { "type": "integer", "minimum": 1, "description": "ID of recipient account" } ] }, "signature": { "type": "string", "minLength": 1, "maxLength": 255 } } } } }, "required": true }, "responses": { "200": { "description": "Successful response", "content": { "application/json": { "schema": { "type": "array", "description": "Array that contains remittance recipient accounts", "items": { "$ref": "#/components/schemas/RecipientAccount" } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "description": "Request for retrieving remittance recipient accounts" } }, "/v2/recipient-account/create": { "post": { "summary": "/v2/recipient-account/create", "operationId": "POST_v2-recipient-account-create", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "info" ], "type": "object", "properties": { "general": { "type": "object", "required": [ "project_id", "signature" ], "properties": { "project_id": { "type": "integer", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature generated on the basis of request parameters by using the project secret key. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } } }, "info": { "type": "object", "required": [ "title" ], "properties": { "title": { "type": "string", "maxLength": 64 } } }, "recipient_info": { "type": "object", "properties": { "beneficiary_account": { "type": "string", "minLength": 4, "maxLength": 32 }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Currency in the ISO 4217 alpha-3 format" }, "remittance_description": { "type": "string", "minLength": 4, "maxLength": 128 }, "beneficiary_name": { "type": "string", "minLength": 4, "maxLength": 128 }, "beneficiary_bank_name": { "type": "string", "minLength": 4, "maxLength": 128 }, "beneficiary_bank_code": { "type": "string", "minLength": 4, "maxLength": 64 }, "beneficiary_bank_country": { "type": "string", "pattern": "^[A-Z]{2}$" }, "recipient_bank_address": { "type": "string", "minLength": 4, "maxLength": 128 } } }, "remittance_details": { "type": "object", "properties": { "monthly_min_amount": { "type": "integer", "minimum": 1, "maximum": 100000000 }, "transfer_max_amount": { "type": "integer", "minimum": 1, "maximum": 100000000 }, "remittance_velocity": { "type": "integer", "minimum": 1 } } }, "company_info": { "type": "object", "properties": { "legal_address": { "type": "string", "minLength": 4, "maxLength": 128 }, "legal_country": { "type": "string", "pattern": "^[A-Z]{2}$" }, "legal_city": { "type": "string", "minLength": 1, "maxLength": 128 }, "zip_code": { "type": "string", "maxLength": 64 } } } } } } }, "required": true }, "responses": { "200": { "description": "ID of created recipient account", "content": { "application/json": { "schema": { "type": "object", "required": [ "info" ], "properties": { "info": { "type": "object", "required": [ "id" ], "properties": { "id": { "type": "integer" } } } } } } } }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "description": "Request for creating a remittance recipient account" } }, "/v2/recipient-account/update": { "post": { "summary": "/v2/recipient-account/update", "operationId": "POST_v2-recipient-account-update", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "info" ], "type": "object", "properties": { "general": { "type": "object", "required": [ "project_id", "signature" ], "properties": { "project_id": { "type": "integer", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature generated on the basis of request parameters by using the project secret key. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } } }, "info": { "type": "object", "required": [ "id" ], "properties": { "id": { "type": "integer" }, "title": { "type": "string", "maxLength": 64 } } }, "recipient_info": { "type": "object", "properties": { "beneficiary_account": { "type": "string", "minLength": 4, "maxLength": 32 }, "currency": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "Currency in the ISO 4217 alpha-3 format" }, "remittance_description": { "type": "string", "minLength": 4, "maxLength": 128 }, "beneficiary_name": { "type": "string", "minLength": 4, "maxLength": 128 }, "beneficiary_bank_name": { "type": "string", "minLength": 4, "maxLength": 128 }, "beneficiary_bank_code": { "type": "string", "minLength": 4, "maxLength": 64 }, "beneficiary_bank_country": { "type": "string", "pattern": "^[A-Z]{2}$" }, "recipient_bank_address": { "type": "string", "minLength": 4, "maxLength": 128 } } }, "remittance_details": { "type": "object", "properties": { "monthly_min_amount": { "type": "integer", "minimum": 1, "maximum": 100000000 }, "transfer_max_amount": { "type": "integer", "minimum": 1, "maximum": 100000000 }, "remittance_velocity": { "type": "integer", "minimum": 1 } } }, "company_info": { "type": "object", "properties": { "legal_address": { "type": "string", "minLength": 4, "maxLength": 128 }, "legal_country": { "type": "string", "pattern": "^[A-Z]{2}$" }, "legal_city": { "type": "string", "minLength": 1, "maxLength": 128 }, "zip_code": { "type": "string", "maxLength": 64 } } } } } } }, "required": true }, "responses": { "200": { "description": "Recipient account was updated" }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "description": "Request for updating a remittance recipient account" } }, "/v2/recipient-account/send-for-approval": { "post": { "summary": "/v2/recipient-account/send-for-approval", "operationId": "POST_v2-recipient-account-send-for-approval", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "info" ], "type": "object", "properties": { "general": { "type": "object", "required": [ "project_id", "signature" ], "properties": { "project_id": { "type": "integer", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature generated on the basis of request parameters by using the project secret key. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } } }, "info": { "type": "object", "required": [ "id" ], "properties": { "id": { "type": "integer" } } } } } } }, "required": true }, "responses": { "200": { "description": "Recipient account was sent to approval" }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "description": "Request for sending a remittance recipient account for approval" } }, "/v2/recipient-account/delete": { "post": { "summary": "/v2/recipient-account/delete", "operationId": "POST_v2-recipient-account-delete", "requestBody": { "content": { "application/json": { "schema": { "required": [ "general", "info" ], "type": "object", "properties": { "general": { "type": "object", "required": [ "project_id", "signature" ], "properties": { "project_id": { "type": "integer", "minimum": 1, "maximum": 4294967295 }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature generated on the basis of request parameters by using the project secret key. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" } } }, "info": { "type": "object", "required": [ "id" ], "properties": { "id": { "type": "integer" } } } } } } }, "required": true }, "responses": { "200": { "description": "Recipient account was deleted" }, "400": { "description": "Validation errors", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "422": { "description": "Invalid JSON data", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } }, "500": { "description": "Internal server error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorResponse" } } } } }, "description": "Request for deleting a remittance recipient account" } } }, "components": { "schemas": { "GeneralInfo": { "required": [ "payment_id", "project_id", "signature" ], "type": "object", "properties": { "project_id": { "type": "integer", "description": "Identifier of merchant project received from Ecommpay", "minimum": 1, "maximum": 4294967295 }, "payment_id": { "type": "string", "minLength": 1, "maxLength": 255, "strict": true, "description": "Identifier of the payment, must be unique within the project. Any letters, digits, and symbols in UTF-8 encoding can be used, except when certain characters occur at the beginning and/or at the end of the string. These characters include a space, a horizontal tab, a null byte, a vertical tab, a newline/line feed, and a carriage return" }, "signature": { "type": "string", "minLength": 1, "maxLength": 255, "description": "Digital signature generated on the basis of request parameters by using the project secret key. For more information, see [Signature generation and verification](https://developers.ecommpay.com/en/en_Gate_Authentication.html)" }, "terminal_callback_url": { "type": "string", "maxLength": 255, "description": "URL for callbacks receivied by Payment Page" }, "referrer_url": { "type": "string", "maxLength": 255, "description": "Site URL from which a customer was redirected to Payment Page" }, "merchant_callback_url": { "type": "string", "minLength": 1, "maxLength": 255, "description": "URL for callbacks receivied by Merchant" } }, "description": "Object that contains general request details" }, "SourceInfo": { "type": "integer", "properties": { "id": { "type": "integer", "enum": [ 7 ], "description": "Interface type which is used for payment performing: 7 - Payment Page in iframe mode" }, "user": { "type": "string", "maxLength": 255, "format": "email", "description": "User's email from the source" } }, "required": [ "id" ] }, "GateSuccessResponse": { "required": [ "payment_id", "project_id", "request_id", "status" ], "type": "object", "properties": { "status": { "type": "string", "maxLength": 255, "description": "Request registration status" }, "request_id": { "type": "string", "maxLength": 100, "description": "Identifier of the request in the payment platform" }, "project_id": { "type": "integer", "description": "Identifier of merchant project received from Ecommpay" }, "payment_id": { "type": "string", "maxLength": 255, "description": "Identifier of the payment, must be unique within project. Any letters, digits, and symbols in UTF-8 encoding can be used" } }, "description": "Object that contains information about request acceptance or execution in the payment platform" }, "ErrorResponse": { "required": [ "status" ], "type": "object", "properties": { "status": { "type": "string", "description": "Status of receiving of the request" }, "code": { "type": "string", "description": "Error code" }, "message": { "type": "string", "description": "Message that clarifies the cause of the error" } }, "description": "Object that contains information about request registration or processing error. Detailed information about the error see in the message parameter of the response" }, "RecipientAccount": { "type": "object", "required": [ "general", "info" ], "properties": { "general": { "type": "object", "required": [ "project_id" ], "properties": { "project_id": { "type": "integer", "description": "Identifier of merchant project received from Ecommpay" } } }, "info": { "type": "object", "required": [ "id" ], "properties": { "id": { "type": "integer" }, "title": { "type": "string" }, "status": { "type": "string" }, "exp_date": { "type": "string" }, "created_date": { "type": "string" }, "updated_date": { "type": "string" } } }, "recipient_info": { "type": "object", "properties": { "beneficiary_account": { "type": "string" }, "currency": { "type": "string" }, "remittance_description": { "type": "string" }, "beneficiary_name": { "type": "string" }, "beneficiary_bank_name": { "type": "string" }, "beneficiary_bank_code": { "type": "string" }, "beneficiary_bank_country": { "type": "string" }, "recipient_bank_address": { "type": "string" } } }, "recipient_details": { "type": "object", "properties": { "monthly_min_amount": { "type": "integer" }, "transfer_max_amount": { "type": "integer" }, "remittance_velocity": { "type": "integer" }, "during_days": { "type": "integer" } } }, "payment_methods": { "type": "array", "items": { "type": "string" } }, "company_info": { "type": "object", "properties": { "legal_address": { "type": "string" }, "legal_country": { "type": "string" }, "legal_city": { "type": "string" }, "zip_code": { "type": "string" } } } } } } }, "tags": [ { "name": "Remittances" } ] } --- # Gate2Asia {#en_gate2asia_info} A section about a package solution from Ecommpay aimed to simplify business operations in Southeast Asia, with a range of payment methods most popular in this region and specific capabilities that allow adapting efficiently to the local payment landscape. ## Overview {#section_tm2_shm_vdc .section} Gate2Asia is a package solution from Ecommpay aimed to simplify business operations in Southeast Asia, a region where electronic payments have permeated all social spheres and that has high potential of economic growth. As part of the Gate2Asia package, Ecommpay offers a range of payment methods most popular in these countries and specific capabilities that allow one to adapt most efficiently to the local payment landscape. Gate2Asia offers coverage in the following countries and special adminstrative regions. | |Country|Population|GDP \(million USD\) |E-commerce \(million USD\) | |--|-------|----------|------------------------|-------------------------------| |![](images/pm/flags/china.svg)|[China](en_gate2asia_china.md)|`1` `412` `175` `000`|`17` `794` `782`|`2` `200` `000`| |![](images/pm/flags/hongkong.svg)|[Hong Kong](en_gate2asia_hongkong.md)|`7` `346` `000`|`382` `055`|`20` `300`| |![](images/pm/flags/indonesia.svg)|[Indonesia](en_gate2asia_indonesia.md)|`275` `501` `000`|`1` `371` `171`|`45` `000`| |![](images/pm/flags/malaysia.svg)|[Malaysia](en_gate2asia_malaysia.md)|`33` `938` `000`|`399` `649`|`10` `100`| |![](images/pm/flags/philippines.svg)|[Philippines \(the\)](en_gate2asia_philippines.md)|`115` `559` `000`|`437` `146`|`20` `000`| |![](images/pm/flags/thailand.svg)|[Thailand](en_gate2asia_thailand.md)|`71` `697` `000`|`514` `945`|`22` `000`| |![](images/pm/flags/vietnam.svg)|[Vietnam](en_gate2asia_vietnam.md)|`98` `186` `000`|`429` `717`|`20` `000`| **Note:** The table cites data for each of the countries from the following sources: [The Global Payments Report](https://worldpay.globalpaymentsreport.com/en) and [World Bank World Development Indicators](https://datacatalog.worldbank.org/search/dataset/0037712) \(2023\). 1. Population—the overall number of people. 2. GDP—gross domestic product. 3. E-commerce—the total volume of electronic payments. ## Setup and configuration {#section_agy_thm_vdc .section} When you set up Gate2Asia, you can select countries, payment methods, and payment currencies that you need and together with the Ecommpay specialists configure the operating modes of the payment form and payment processing that match the specific characteristics of the selected countries and your business goals. Fine-tuning can involve any functionality of the Ecommpay payment platform. However, the most relevant and site specific for working in the Southeast Asian countries are the capabilities of the payment method parametric filtering and applying additional rules of risk assessment. *Managing payment method availability by parametric filtering* is a capability that allows your customer to select those payment methods that are optimal for each specific purchase depending on the currency or the country specified in the request. When a wide range of local payment methods is used \(which is often the case in the region\), this filtering option can significantly improve convenience of user scenarios and the speed with which customers interact with the payment form. For more information, refer to the following article: [Managing payment methods availability](en_pp_methods_availability.md#). *Applying additional risk assessment rules when local payment methods are used* allows you to set up and maintain an extended set of rules based on the information about customers, their devices, and payment profiles and also adapted to the regional specifics. It helps you provide higher level of fraud prevention when you work in these countries. The general information about risk assessment for payment processing via the platform can be found in the following article: [Risk management](en_dbl_risks.md#). If you have any questions concerning the terms and conditions of setting up the Gate2Asia solution and relevant additional capabilities, contact your Ecommpay account manager. If your company is not yet the client of Ecommpay, you can apply [here](https://ecommpay.com/apply-now/). - **[China](en_gate2asia_china.md)** An article with the general information about electronic payments in China and the payment methods available for payment processing in this country as part of the Gate2Asia solution. - **[Hong Kong](en_gate2asia_hongkong.md)** An article with the general information about electronic payments in Hong Kong and the payment methods available for payment processing in this region as part of the Gate2Asia solution. - **[Indonesia](en_gate2asia_indonesia.md)** An article with the general information about electronic payments in Indonesia and the payment methods available for payment processing in this country as part of the Gate2Asia solution. - **[Malaysia](en_gate2asia_malaysia.md)** An article with the general information about electronic payments in Malaysia and the payment methods available for payment processing in this country as part of the Gate2Asia solution. - **[Philippines \(the\)](en_gate2asia_philippines.md)** An article with the general information about electronic payments in the Philippines and the payment methods available for payment processing in this country as part of the Gate2Asia solution. - **[Thailand](en_gate2asia_thailand.md)** An article with the general information about electronic payments in Thailand and the payment methods available for payment processing in this country as part of the Gate2Asia solution. - **[Vietnam](en_gate2asia_vietnam.md)** An article with the general information about electronic payments in Vietnam and the payment methods available for payment processing in this country as part of the Gate2Asia solution. --- # China {#en_gate2asia_china} An article with the general information about electronic payments in China and the payment methods available for payment processing in this country as part of the Gate2Asia solution. ![](images/pm/flags/china.svg)China is a country with the population of about 1.4 billion people and the GDP per capita of about 12 thousand USD. Its economy and the e-commerce industry are developing rapidly. In 2024 \(according to [Global Payments Report 2024](https://worldpay.globalpaymentsreport.com/)\), the distribution of the electronic payments in China was as follows: - Card payments—10 %. - Bank payments—2 %. - Digital wallet payments—82 %. - Other types of payments—6 %. As part of the Gate2Asia package, the Ecommpay payment platform offers a variety of methods popular in this country, first and foremost, for online banking and digital wallet payments. | |Method|Type|Purchases|Payouts| |--|------|----|:-------:|:-----:| |![](images/pm/methods_icon/pm_alipay.svg)|[Alipay](pm_alipay.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_unionpay.svg)|[China UnionPay](pm_unionpay.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_wechat.svg)|[WeChat](pm_wechat.md#)|digital wallet payments|+|–| If you have any questions about terms and conditions of integrating Chinese payment methods, or you need information about other Gate2Asia methods, refer to your Ecommpay account manager. **Parent topic:**[Gate2Asia](en_gate2asia_info.md) --- # Hong Kong {#en_gate2asia_hongkong} An article with the general information about electronic payments in Hong Kong and the payment methods available for payment processing in this region as part of the Gate2Asia solution. ![](images/pm/flags/hongkong.svg)Hong Kong is a special administrative region of China with the population of about 7.3 million people and the GDP per capita of about 50 thousand USD. Its economy and the e-commerce industry are developing rapidly. In 2024 \(according to [Global Payments Report 2024](https://worldpay.globalpaymentsreport.com/)\), the distribution of the electronic payments in Hong Kong was as follows: - Card payments—44 %. - Bank payments—15 %. - Digital wallet payments—32 %. - Other types of payments—9 %. As part of the Gate2Asia package, the Ecommpay payment platform offers a variety of methods popular in this region, first and foremost, for online banking. | |Method|Type|Purchases|Payouts| |--|------|----|:-------:|:-----:| |![](images/pm/methods_icon/pm_hk_banks.svg)|[Banks of Hong Kong](pm_hk_banks.md#)|bank payments|–|+| |![](images/pm/methods_icon/pm_hk_qr.svg)|[Hong Kong FPS QR](pm_hk_qr.md#)|bank payments|+|–| If you have any questions about terms and conditions of integrating Hong Kong payment methods, or you need information about other Gate2Asia methods, refer to your Ecommpay account manager. **Parent topic:**[Gate2Asia](en_gate2asia_info.md) --- # Indonesia {#en_gate2asia_indonesia} An article with the general information about electronic payments in Indonesia and the payment methods available for payment processing in this country as part of the Gate2Asia solution. ![](images/pm/flags/indonesia.svg)Indonesia is a country with the population of about 275.5 million people and the GDP per capita of about 5 thousand USD. Its economy and the e-commerce industry are developing rapidly. In 2024 \(according to [Global Payments Report 2024](https://worldpay.globalpaymentsreport.com/)\), the distribution of the electronic payments in Indonesia was as follows: - Card payments—17 %. - Bank payments—28 %. - Digital wallet payments—40 %. - Other types of payments—15 %. As part of the Gate2Asia package, the Ecommpay payment platform offers a variety of methods popular in this country, first and foremost, for online banking, digital wallet and QR code payments. | |Method|Type|Purchases|Payouts| |--|------|----|:-------:|:-----:| |![](images/pm/methods_icon/pm_doku.svg)|[DOKU Wallet](pm_doku.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_indonesia.svg)|[Indonesian Online Banking](pm_indonesia.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_indonesia_va.svg)|[Indonesian Virtual Accounts](pm_indonesia_va.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_ovo.svg)|[OVO Wallet](pm_ovo.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_qris.svg)|[QRIS](pm_qris.md#)|QR code payments|+|–| If you have any questions about terms and conditions of integrating Indonesian payment methods, or you need information about other Gate2Asia methods, refer to your Ecommpay account manager. **Parent topic:**[Gate2Asia](en_gate2asia_info.md) --- # Malaysia {#en_gate2asia_malaysia} An article with the general information about electronic payments in Malaysia and the payment methods available for payment processing in this country as part of the Gate2Asia solution. ![](images/pm/flags/malaysia.svg)Malaysia is a country with the population of about 33.9 million people and the GDP per capita of about 12 thousand USD. Its economy and the e-commerce industry are developing rapidly. In 2024 \(according to [Global Payments Report 2024](https://worldpay.globalpaymentsreport.com/)\), the distribution of the electronic payments in Malaysia was as follows: - Card payments—27 %. - Bank payments—39 %. - Digital wallet payments—24 %. - Other types of payments—10 %. As part of the Gate2Asia package, the Ecommpay payment platform offers a variety of methods popular in this country, first and foremost, for online banking and digital wallet payments. | |Method|Type|Purchases|Payouts| |--|------|----|:-------:|:-----:| |![](images/pm/methods_icon/pm_boost.svg)|[Boost Wallet](pm_boost.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_grabpay.svg)|[GrabPay](pm_grabpay.md#)\*|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_malaysia.svg)|[Malaysian Online Banking](pm_malaysia.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_shopee.svg)|[Shopee](pm_shopee.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_touchngo.svg)|[Touch&Go](pm_touchngo.md#)|digital wallet payments|+|+| You can learn how to work with each of these methods in a corresponding article. It should also be noted that [GrabPay](pm_grabpay.md#) allows processing payouts in the Philippines, in Philippine pesos. If you have any questions about terms and conditions of integrating Malaysian payment methods, or you need information about other Gate2Asia methods, refer to your Ecommpay account manager. **Parent topic:**[Gate2Asia](en_gate2asia_info.md) --- # Philippines \(the\) {#en_gate2asia_philippines} An article with the general information about electronic payments in the Philippines and the payment methods available for payment processing in this country as part of the Gate2Asia solution. ![](images/pm/flags/philippines.svg)The Philippines is a country with the population of about 115.5 million people and the GDP per capita of about 3.5 thousand USD. Its economy and the e-commerce industry are developing rapidly. In 2024 \(according to [Global Payments Report 2024](https://worldpay.globalpaymentsreport.com/)\), the distribution of the electronic payments in the Philippines was as follows: - Card payments—31 %. - Bank payments—16 %. - Digital wallet payments—34 %. - Other types of payments—19 %. As part of the Gate2Asia package, the Ecommpay payment platform offers a variety of methods popular in this country, first and foremost, for online banking and digital wallet payments. | |Method|Type|Purchases|Payouts| |--|------|----|:-------:|:-----:| |![](images/pm/methods_icon/pm_maya.svg)|[Maya](pm_maya.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_philippines_atm.svg)|[Philippines Over the Counter & ATM](pm_philippines_atm.md#)|bank payments|+|–| |![](images/pm/methods_icon/pm_philippines.svg)|[Banks of the Philippines](pm_philippines.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_coinsph.svg)|[Coins.ph](pm_coinsph.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_gcash.svg)|[GCash](pm_gcash.md#)|digital wallet payments|+|+| |![](images/pm/methods_icon/pm_grabpay.svg)|[GrabPay](pm_grabpay.md#)|digital wallet payments|+|+| If you have any questions about terms and conditions of integrating Philippine payment methods, or you need information about other Gate2Asia methods, refer to your Ecommpay account manager. **Parent topic:**[Gate2Asia](en_gate2asia_info.md) --- # Thailand {#en_gate2asia_thailand} An article with the general information about electronic payments in Thailand and the payment methods available for payment processing in this country as part of the Gate2Asia solution. ![](images/pm/flags/thailand.svg)Thailand is a country with the population of about 71.6 million people and the GDP per capita of about 7 thousand USD. Its economy and the e-commerce industry are developing rapidly. In 2024 \(according to [Global Payments Report 2024](https://worldpay.globalpaymentsreport.com/)\), the distribution of the electronic payments in Thailand was as follows: - Card payments—18 %. - Bank payments—44 %. - Digital wallet payments—27 %. - Other types of payments—11 %. As part of the Gate2Asia package, the Ecommpay payment platform offers a variety of methods popular in this country, first and foremost, for online banking and QR code payments. | |Method|Type|Purchases|Payouts| |--|------|----|:-------:|:-----:| |![](images/pm/methods_icon/pm_promptpay.svg)|[Promptpay](pm_promptpay.md#)|QR code payments|+|–| |![](images/pm/methods_icon/pm_thailand.svg)|[Thai Online Banking](pm_thailand.md#)|bank payments|+|+| |![](images/pm/methods_icon/pm_truemoney.svg)|[TrueMoney](pm_truemoney.md#)|QR code payments|+|–| If you have any questions about terms and conditions of integrating Thai payment methods, or you need information about other Gate2Asia methods, refer to your Ecommpay account manager. **Parent topic:**[Gate2Asia](en_gate2asia_info.md) --- # Vietnam {#en_gate2asia_vietnam} An article with the general information about electronic payments in Vietnam and the payment methods available for payment processing in this country as part of the Gate2Asia solution. ![](images/pm/flags/vietnam.svg)Vietnam is a country with the population of about 98.1 million people and the GDP per capita of about 4 thousand USD. Its economy and the e-commerce industry are developing rapidly. In 2024 \(according to [Global Payments Report 2024](https://worldpay.globalpaymentsreport.com/)\), the distribution of the electronic payments in Vietnam was as follows: - Card payments—25 %. - Bank payments—20 %. - Digital wallet payments—36 %. - Other types of payments—19 %. As part of the Gate2Asia package, the Ecommpay payment platform offers a variety of methods popular in this country, first and foremost, for online banking and digital wallet payments. | |Method|Type|Purchases|Payouts| |--|------|----|:-------:|:-----:| |![](images/pm/methods_icon/pm_momoqr.svg)|[MoMo Wallet](pm_momoqr.md#)|digital wallet payments|+|–| |![](images/pm/methods_icon/pm_vietnam.svg)|[Vietnamese Online Banking](pm_vietnam.md#)|bank payments|+|+| If you have any questions about terms and conditions of integrating Vietnamese payment methods, or you need information about other Gate2Asia methods, refer to your Ecommpay account manager. **Parent topic:**[Gate2Asia](en_gate2asia_info.md) --- # Xero integration {#en_xero} A section about working with the Ecommpay web application for integration with the Xero platform. This section covers the information on integration with the Xero cloud-based accounting platform. - [General information](en_xero_overview.md#)describes core capabilities and special aspects of integration with Xero. - [Integration](en_xero_integration.md#)contains guides on how to connect and set up the application from Ecommpay. - [Working with the Xero accounts](en_xero_accounts.md#)explains how to set up accounts in Xero and use them for interaction with the Ecommpay platform. - [Working with the Xero invoices](en_xero_invoices.md#)describes capabilities, scenarios, and key procedures for accepting payments with the use of one-time and repeating invoices that are initiated in Xero and processed via the Ecommpay platform. - **[General information](en_xero_overview.md#)** An article with the introductory information about the core capabilities and special aspects of integration with Xero. - **[Integration](en_xero_integration.md#)** An article with the guides on how to connect and set up the application from Ecommpay for working with Xero. - **[Working with the Xero accounts](en_xero_accounts.md#)** An article about settings up accounts in Xero for interaction with the Ecommpay platform. - **[Working with the Xero invoices](en_xero_invoices.md#)** An article about the capabilities, scenarios, and key procedures for accepting payments with the use of one-time and repeating invoices that are initiated in Xero and processed via the Ecommpay platform. --- # FAQ {#en_faq} A section with the answers to commonly asked questions concerning the platform and its use. This section provides answers to questions that are commonly asked by the merchants' technical specialists. These questions are divided into the following groups: - [Integration](en_faq_integration.md) covers questions about integration process including configuration and testing of various functionalities. - [Payments](en_faq_payment_processing.md) covers questions about processing different types of payments, operations, and performing procedures as well as the rules for specifying different parameters in requests. - [Callbacks](en_faq_callbacks.md) covers questions about callbacks sent from the payment platform including their parameters and configuration. - [Results](en_faq_payment_result.md) covers questions about control and interpretation of different payment results, operations, and procedures performed within the platform. - [Chargebacks](en_faq_chargebacks.md) covers questions about working with chargebacks on payments processed via the payment platform, largely in cases when Ecommpay acts as an acquirer. If the information provided here and in other sections of the documentation is not enough to solve your problems, contact our specialists: - with business and financial issues \(the cost of services, calculating commissions, working with balance sheets, and other questions\), contact your key account manager; - with technical issues \(working with different interfaces, making requests, and other questions\), contact the technical support specialists \([support@ecommpay.com](mailto:support@ecommpay.com)\). - **[Integration](en_faq_integration.md)** An article with answers to questions about integration process including configuration and testing of various functionalities. - **[Payments](en_faq_payment_processing.md)** An article with answers to questions about processing different types of payments and operations, performing procedures, and the rules for specifying different parameters in requests. - **[Callbacks](en_faq_callbacks.md)** An article with answers to questions about working with callbacks sent from the payment platform. - **[Results](en_faq_payment_result.md)** An article with answers to questions about monitoring and interpreting results of payments, operations, and procedures performed within the platform. - **[Chargebacks](en_faq_chargebacks.md)** An article with answers to questions about working with chargebacks on payments processed via the payment platform, largely in cases when Ecommpay acts as an acquirer. --- # Integration {#en_faq_integration} An article with answers to questions about integration process including configuration and testing of various functionalities. This subsection provides answers to questions about integration process including configuration and testing of various functionalities. Payment Card Industry Data Security Standard \([PCI DSS](https://www.pcisecuritystandards.org/pci_security/)\) is a standard for the proper protection of payment card data. It is developed by the PCI Security Standards Council \(PCI SSC\) and sets requirements for all companies involved in processing, storing, or transmitting payment card data. Complying with the PCI DSS requirements is absolutely mandatory: no parties involved in processing card payments are allowed to process such payments otherwise. To prove the compliance with the PCI DSS requirements and be allowed to process card payments, merchants are required to provide the corresponding documents to payment systems \(such as Visa, Mastercard, and Amex\) in time, directly or through providers. Depending on a payment system, there can be different requirements to such documents with regards to the data breach incidents and other cases. Therefore, the necessity for a particular merchant to provide certain documents is considered on a case-by-case basis. In the case of the Visa and Mastercard payment systems, the PCI DSS compliance documents should be provided to Ecommpay. Thus the following documents are required: - From all merchants—[the ASV scan](en_glossary.md#) report. The ASV scanning must be performed by the authorised scanning service providers \(PCI SSC Approved Scanning Vendor, ASV\) quarterly and after every significant change in the network infrastructure.The Ecommpay merchants can select these providers on their own and, if relevant, have the scanning procedure performed by the Ecommpay partner. To have the scanning service via the partner organised, contact the key account manager. - From the merchants processing over 6 million operations annually \(Level 1\)—the Attestation of Compliance, AOC. - From the merchants processing to 6 million operations annually \(Levels 2, 3, and 4\)—the Self-Assessment Questionnaire, SAQ. With questions on completing the questionnaire, contact the Ecommpay key account manager. After all required documents have been checked, the merchant can start processing card payments—the merchant is informed about this \(as well as about the expiration of the documents validity period\) by the Ecommpay key account manager. In the case of other payment systems, the PCI DSS compliance documents usually should be provided directly to these payment systems, however, the merchants can consult with the key account manager about the necessity of providing these documents to Ecommpay. As a rule, during the integration process, merchants get access first to the test environment to try essential workflows without processing real payments, then to the production environment in order to deploy customised and tested solutions. For these purposes, the Ecommpay technical support specialists create and configure two projects of interaction with the merchants' web services—a test project and a production project—with specific identifiers for each of them \(`project_id`\). Changing a project ID in requests turns the test environment into the real one. Since sets of parameters and addresses for receiving requests in the two environments are identical, it is important not to confuse the project IDs and handle them properly. By default, the technical support specialists provide merchants with a single test project, but it is possible to create additional projects on request. Note that the test environment has a limited number of available payment methods and scenarios. For more information, see the corresponding sections on testing via direct use of payment cards \([Test cards](en_test_cards.md)\)and alternative payment methods \(for example, [testing Google Pay](pm_googlepay.md#)\). All test payments are processed in the platform like the ones in the production environment: they are registered in the platform with the information about them displayed in the Dashboard interface, and the details of payment instruments are processed and protected without actual debiting taking place. Therefore, testing provides you with a complete picture of the work process when you can use real data of payment cards, wallets, and other instruments without running risks of payment information misuse. The environment in each of these cases can be defined as a set of internal software components in the platform that emulate payments in test mode and actually process payments in production mode. Each of the Ecommpay payment platform interfaces uses its own base URL. This is important to keep in mind, for example, when you use Payment Page and Gate for different actions: you can generate a token via Payment Page and then make a payout with this token via Gate.In this case, you use two different URLs: `https://paymentpage.ecommpay.com` and `https://api.ecommpay.com` for Payment Page and Gate respectively. To request balance information about this payout via Data API, you can use yet another base URL: `https://data.ecommpay.com/v1`. Information about the base URLs, request structures, and other features of the interfaces is provided in sections with the descriptions of these interfaces. The URLs for program and customer actions are listed below: - `https://api.ecommpay.com` is for interaction via Gate. For example, the URL for a payment status request is `https://api.ecommpay.com/v2/payment/status`. For more information about working with the Gate API requests, see [Request format](en_gate_interaction_organisation.md#). - `https://paymentpage.ecommpay.com` is for interaction via Payment Page. For example, a GET payment request is `GET /payment?payment_currency=EUR&project_id=42&payment_amount=1000&... HTTP/1.1 Host: https://paymentpage.ecommpay.com`. For more information about working with the Payment Page API requests, see [Request format](en_pp_interaction_organisation.md#). - `https://data.ecommpay.com/v1` is for interaction via Data API. For example, the URL for an account balances request is `https://data.ecommpay.com/v1/balance/get`. For more information about working with the Data API requests, see [Using Data API](en_dbl_api_protocol.md). - [dashboard.ecommpay.com](https://dashboard.ecommpay.com) is for merchant employees to access the Dashboard web interface. *Payment* within the platform is a comprehensive record of one settlement between a merchant and a customer.A single payment may include a one-time cash flow—from the customer to the merchant \(purchase\)or vice versa \(payout\)—or a repeated cash flow—for example, a purchase followed by a refund or a series of debiting payments. The payment is considered completed upon settlement between the merchant and the customer as part of the service provided by the merchant \(which includes the corresponding payment request initiated by the merchant\).Like in everyday life, the purchase can change its final state—it can be completed with the status of `success` and subsequently get the status of `partially refunded`. *Operation* within the platform is a single action with funds performed during a payment.An operation can include placing a hold on funds for their consequent debiting, the debiting itself, refund, or payout. Processing a single payment may require one or more operations. Such a division is helpful in terms of controlling settlements at the level of payments and specific operations. Each payment in the platform has its identifier \(`payment_id`\) that is unique within a project. Such IDs can include numbers, Latin letters, and other characters in the UTF-8 encoding, and their length must not exceed 255 characters—for example, *payment-123*or *cosmoshop.sale\_456*. If a request is valid, the payment is registered in the platform and the appropriate operation is initiated for this payment. Each operation gets an identifier \(`operation_id`\) that is unique within the platform. These IDs are passed in callbacks, and you can use them in the Dashboard interface. Note that a payment and the operations within the payment can have different statuses. For example, a payment with the `refunded` status includes the refund operation with the `success` status. For more information about the differences and features of these concepts, see [Payment processing](en_platform_payment_model.md). - [Purchase](en_Gate_purchase.md) is a payment with a transfer of money from a customer to a merchant. It can include payments for goods and services, booking or reservation prepayments, subscription payments, and so on. A purchase can be a one-time or recurring payment, and it can also be refunded in certain cases. - [Refund](en_Gate_Refund.md) is the operation of returning the money from a merchant to a customer after a purchase. This can refer to cancelling reservations or returning goods. Along with that, refunds can be full \(the customer gets the entire amount\) and partial \(the customer gets a part of the previously paid amount\). - [Payout](en_Gate_payout.md) is a payment with a transfer of money from a merchant to a customer. This can refer to receiving prize money, bonuses, or compensation for expenses. Purchases can be made using all interfaces of the platform. Payouts and refunds are initiated through the Gate API and Dashboard.While these features are supported for the card payment methods, some of them may be unavailable for alternative payment methods. For up-to-date information about individual payment methods, see their descriptions in the corresponding sections. In short, the choice between one-step or two-step purchases depends on how quickly funds are debited and how quickly and easily they can be partially or fully returned after a payment is made. A one-step purchase implies debiting funds without delay—as quickly as it is done in the payment systems. This is a good option when it comes to paying for goods or actually provided services and the amount of payment is fixed and can not be changed. To return the funds to the customer upon completing a one-step purchase, you need to issue a full or partial refund.One-step purchases are supported for different payment methods and can be used for loan repayment to microfinance organisations. For more information about this type of payment, see [One-step purchase](en_gate_payment_sale.md#). A two-step purchase includes two stages: placing a hold on funds, and after confirmation, debiting or returning them to the customer. The total amount of money that is to be eventually debited or returned can change from the previously held amount. This is a good option for different types of booking and renting services, services with prepayments and insurance premiums, and others. In such cases, the held funds can be debited upon the merchant's confirmation request or after a specified period of time. If the funds have not been debited, you can return them to the customer by releasing the hold on funds. If the funds have been debited, you can issue a refund \(the same way it is done with one-step purchases\). Two-step purchases are currently supported only for payment cards.For more information about this type of payment, see [Two-step purchase](en_gate_payment_auth.md#). You can always consult the Ecommpay key account managers on choosing the most suitable option for your businesssphere in particular regions. Payment methods within the Ecommpay platform are ways of making payments characterised by supported operations, currencies, payment instruments, and user scenarios. The availability of these methods varies on a regional basis. For example, purchases made in Indonesian rupiah through online banking systems and purchases in the same currency by using e-wallets are two different payment methods. Thus, such characteristics specific to different regions and business spheres give relevance to the plethora of payment methods available within the platform. The Ecommpay key account managers can provide you with deeper insights into specific payment methods and differences between them and help you select methods most suitable for your business activities. **Parent topic:**[FAQ](en_faq.md) --- # Payments {#en_faq_payment_processing} An article with answers to questions about processing different types of payments and operations, performing procedures, and the rules for specifying different parameters in requests. This section provides answers to questions on how to initiate and processvarious paymenttypes boosting payment acceptance rates and addressing typical and atypical tasks. The questions of this group focus on how to minimise payment rejections by specifying parameters properlyand set up solutions for currency conversion. The questions also focus on how to return funds to customersand reverse such refunds and payouts when required. ## Why do I need different sets of required parameters in requests? {#section_l42_tzx_t1c .section} **Short answer:** the reason for this is that different payment systems and providers use their own workflows and impose various requirements for input data; to optimise the work with payments, it may be beneficial to use the most detailed sets of customer information in requests. The payment platform allows you to perform a wide range of operations with the use of different payment methods. These operations may require participation of different partners\(payment systems and providers\) with their own processing workflows and requirements for payment parameters. Therefore, such parameters as payment description, a customer's phone number or email address, and others can be mandatory or optional in different cases. We strive to ensure the maximum availability of payments and operations within the platform by reducing the number of required parameterson a case-by-case basis and specify which parameters are required and which are optional in API specifications and documentation. Along with that, there may be instances when the same parameters can be either mandatory or optional for a single operation within one payment method depending on specific factors\(for example, in case of the AVS check\). In such complex situations, we adopt a special procedure of [submitting additional information](en_Gate_Clarification.md) when the payment is performed. To optimise the work with mandatory and optional parameters, you can set up registration and use of the most complete set of data about customers in each requestsince this information is often required as additional parameters by providers and payment systems. If you have any specific questions about working with parameters, contact the Ecommpay technical support specialists. ## Why do I have to specify a payment method when opening Payment Page? {#section_qsz_q1y_t1c .section} **Short answer:** this simplifies the customer scenario in the payment form, making it more user-friendly by allowing them to choose a payment method directly in the web service or by selecting the preferred method for them. The Payment Page payment form opens by default after the customer selects a payment method on the payment method selection page:![](images/ecommpay/en_faq_payment_processing_1.svg) However, this functionality may not always be relevant. This maybe the case when the customer selects a payment method before opening Payment Page, or when they need a specific payment method for payment operations in a particular region. In such cases, requests for opening Payment Page contain the `force_payment_method` parameter which opens the Payment Page form with a preselected payment method.As a rule, it is the form where the customer enters payment information and other requested details and confirms the payment operation:![](images/ecommpay/en_faq_payment_processing_2.svg) This is useful in terms of improving customer scenarios. Note, however, that when opening Payment Page with a particular method preselected, the customer is restricted in selecting another payment method even in cases when the first payment attempt failed and retry attempts can be used \([details](en_PP_Try_Again.md)\).Thus, preselecting a payment method should be implemented only when it is certain that this specific method is relevant for the customer and this capability can be used in combination with other ones, including the capability of payment retries. More information about preselecting payment methods is provided [in a separate article](en_PP__PreselectingPS.md). Along with that, there are other features that can be useful for optimising customer scenarios and use of payment methods—for example, limiting the list of payment methods\(using the `hide` parameter\)and initialising payments with [payment card tokens](en_PP_Payment_by_token.md). ## Why is it important to pass the customer ID and IP address? {#section_dcx_hby_t1c .section} **Short answer:** These parameters help to deeper analyse payment traffic analysis and bolster fraud prevention measures. Customer IP address and identifier are among the required parameters for performing financial operations within the Ecommpay payment platform. These parameters are necessary when operations are analysed for fraud. With this data omitted or incorrect, operations may be rejected, which results in a decreased conversion rate. ## What is the correct way to specify customers' first and last names? {#section_dbx_kby_t1c .section} **Short answer:** when providing a customer's first and last name, it is crucial that you use correct information \(as it is often used for passing different verification checks\) and comply with the specific requirements that permit the use of various alphabetic and some non-alphabetic characters. Requests to the payment platform may require specifying the first and last names of a customer and/or a cardholder. These parameters are checked not only for correctness of the data format but also according to different rules including fraud prevention rules. Thus, it is important to meet a number of conditions for forming requests. For example, the payment platform does not allow merchants to issue payouts to non-personalised payment cards. Such payments are rejected since it is impossible to check them for sanction restrictions. Moreover,payment systems may check whether the customer's first and last names are specified correctly in accordance with their rules. For correct processing of payments and preventing declines due to errors with first and last names specified, there are the following recommendations: - Use real first and last names\(for example, specifying *CARDHOLDER NAME* or *Customer Name* is incorrect\). - Make sure that each parameter contains at least 2 characters and, if possible, not more than 50 characters. - It is possible to use letters, numbers, and other characters in the UTF-8 encoding. The following additional restrictions apply to the `card_holder` parameter: - It is possible to use: - any alphabetic characters encoded in the Unicode Standard - periods in abbreviations \(for example, *Mr.* or *Jr.*\) - apostrophes \(for example, *d'Arc* or *O'Hara*\) - hyphens in compound names \(for example, *Anna-Maria* or *Jean-Baptiste*\) - Ensure that the value contains at least two words and no more than one period.For example, specifying *Alexandre Dumas Jr.* is possible, while *Mr. Alexandre Dumas Jr.* is incorrect. - Ensure that the value contains a minimum of two words \(mind that both words must contain more than one letter; if there are more than two words—at least two of them must contain more than one letter\) and no more than one period.For example, specifying *M-r Holder* is incorrect since this construction contains three words with two words consisting of a single letter. ## What can be specified in the payment description? {#section_l41_yby_t1c .section} **Short answer:** if this parameter is mandatory, it must contain the reason for processing the operation; if this parameter is optional, it can contain any additional information. Payment requests contain the `description` parameter that can be mandatory\(for example, with refunds\) or optional depending on a payment method and type of operation.If you want to know in what cases this parameter is required, see the sections with the descriptions of payment methods. - If `description` is mandatory, its value must contain an explanation for the operation—for example, *Partially refunded due to partially returned order \(wrong size\)*, *Fully refunded due to technical issues with the service*, or *The full cost of the ticket is refunded due to the session cancellation*. - If `description` is optional, its value can contain any additional information about the payment—for example, *Funding wallet 007*, *Crediting account 271828*, *Payment with a promotion code* or *Withdrawal of funds on request \#314*. If descriptions are provided in requests, they are used in callbacks, displayed in the Dashboard interface, and can be helpful for merchants in payment analysis. ## When and how is currency conversion applied? {#section_lbg_xwd_wbc .section} **Short answer:** conversion is applied when at least one of the currencies involved in the payment processing differs from the others and can be carried out both on the side of the payment service used by the customer and on the side of the Ecommpay payment platform. Every financial operation entails the transfer of funds from a specific ‘source’ to a designated ‘recipient’ through a connecting ‘channel’. In case of the Ecommpay payment platform, these are defined as follows: - The source and the recipient are the customer's payment instrument and the funds of the merchant's balance, respectively \(for purchases, this correlation works as specified, while for refunds, it works in reverse\). - The payment channel is a combination of technical means and logical entities that facilitate the transfer of funds between the payment platform serving the merchant and the payment service serving the customer. When the currency of the customer's payment instrument, the merchant's balance currency, and the payment channel currency are the same, financial operations can be processed without the need for conversion. However, when at least one of the currencies differs from the others, conversion becomes necessaryto enable the transfer of funds through the channel in use. The currency of the channel is considered the actual currency of the operation, also known as the operational or settlement currency\(this can be important for payment accounting, payment analysis,chargebacks resolution, and other related processes\). Thus, the conversion process is structured as follows: - If the currency of the customer's payment instrument differs from the settlement currency, then, to process a payment via the channel, conversion is performed on the side of the organisation that serves this payment instrument. - If the currency of the merchant's balance differs from the settlement currency, then, to process a payment via the channel, conversion is performed on the Ecommpay side. An example scenario would be a Polish customer making a payment in Norwegian krone\(`NOK`\) through a payment channel for a service in Norway, using a card denominated in Polish zloty\(`PLN`\), while the merchant's balance currency is the euro\(`EUR`\). In this case, the conversion from zloty to krone is performed on the issuer's side\(at the rate and terms applied by them\), and the conversion from krone to euro is performed on the Ecommpay side. Additionally, there are scenarios where the initial currency of an operation, as specified in the request, is different from the channel currency. To handle such situations, the payment platform uses an algorithm where the initial amount is converted into the channel currency and the operation is subsequently processed with the converted amount in the channel currency\(additional secondary conversions, as in the provided example, can be applied if relevant\). Along with that, in the standard program callback about the operation processing, the initial amount and currency, submitted in the request, are specified as `sum_initial`, while the convertedsettlement amount and currency are specified as `sum_converted`. In summary, currency conversion during the processing of financial operations is applied as an auxiliary procedure to adjust to the payment channels in use, both on the side of the customer and their payment service and on the side of the merchant and the Ecommpay payment platform. ## How can I optimise the work with different currencies and their conversion? {#section_w5y_wvd_wbc .section} **Short answer:** to reduce the frequency of conversions and potential losses during payment processing, it is advisable to set up variouspayment methods and channels tailored to the merchant's audience and business growth strategies, including the usage of various capabilities and solutions available in the payment platform\(such as enabling [conversion with a customer-selected currency](en_pp_currency_choice.md) when working with Payment Page\). In today's e-commerce landscape, abundant with various paymentmethods, instruments, and currencies, currency conversion plays a crucial role in enabling seamless operation processing and service delivery. However, both customers and merchants are averse to incurring losses through fees and exchange rate differences during conversion. To minimise the need for conversionsand potential losses, merchants can adopt a comprehensive approach in this direction. - Key to this strategy is analysing the audience and their payment preferences, including their geographical locations, favoured paymentmethods and currencies, as well as their frequency of encountering currency conversions. - Aligning the spectrum of paymentmethods and channels with the audience's specifics and the merchant's business development goals is also essential. Collaborating with the Ecommpay account manager can help to optimise the structure of supported currencies, balances, and channels.This may involve setting default currencies for automatic conversions and implementing other advantageous solutions. - Providing users with the option to select their currency can prevent unnecessary conversions.In case of working with the payment form Payment Page, you can have this capability set up in the form \([details](en_pp_currency_choice.md)\). In other cases, such capability can be set up on the web service side. - Facing other issues or challenges related to conversion, you can also contact the Ecommpay specialists—we are always committed to delivering the best service and solving even the most unconventional problems. ## When and how can I return funds to customers? {#section_xyx_kcy_t1c .section} **Short answer:** usually, after processing a purchase, a refund can be issued within this purchase, via the Gate API or Dashboard; besides, in certain cases, customers can be reimbursed in a different way, such as a release of funds as a part of a two-step purchase and a payoutwith the use of a payment method which can be the same method that was used for the purchase or a different one. *The meaning of the term ‘refund’ in the payment platform.* In the Ecommpay payment platform, a refund is an operation of reimbursing a customer for the amount withdrawn from their account for a purchase.In other words, if funds have been taken from a customer during the processing of a payment via the platform, you can make a refund via the platform to return the funds to the customer within the same purchase. All of this is quite straightforward, but let us dig deeper to understand different aspects. *Insights into refunds.* What you need to know to get a better understanding about working with refunds: - Refunds can be full and partial\(for returning either full or partial amount of the purchase\). In the platform, it is possible to issue multiple refunds for a single purchase provided that the amount of each subsequent refund does not exceed theamount that was debited for a purchase and has not been returned to the customer yet with the previous refunds \(this amount is called the actual payment amount\). - Refunds can be unavailable in some cases. While refunding card payments is usually available without restrictions, in case of alternative payment methods the situation can be different: depending on the method, refunds can be supported in full or with restrictions, or not supported at all.For example, issuing partial refunds can be unavailable, or you may be unable to issue any refunds if a time limitation is set for how long a purchase can be refunded after it was completed. What can be done about it? First of all, you can obtain the information whether refunds are supported for each payment method being set up and whether there are any special aspects to be considered in case of refunds. Besides, if refunds are unavailable but the return of funds is needed, you can get the information whether there are other ways to reimburse customers\(for example, by issuing payouts with the use of the same or other payment methods\). In these and other complicated situations, you can be assisted by your Ecommpay account manager. - Refunds can be issued with the use of different technical operations. Depending on the specifics of various payment systems, the technical operation for returning funds can be either `reversal` or `refund`. Normally, the `reversal` operation is used when a refund is made within the operation day on which the corresponding card payment has been processed and the `refund` operation is used in other cases.Along with that, the `reversal` operation can be used, for example, when it is confirmed\(via the `payment confirmation` operation\) that the funds have not been transferred to the customer's account. What can be done about it? Keep in mind that such aspects can be encountered and do not get alarmed when you come across different names of operations. Speaking of the operations' names, all refunds in the Dashboard interface are marked as `refund` operations \(for the sake of simplicity\). If you need to know what operation, `reversal` or `refund`, was actually used for a refund, use program [callbacks](en_platform_callbacks.md#) and, if relevant, [Data API](https://api-data.ecommpay.com/). For more detailed information, refer to the article [Purchase refunds](en_Gate_Refund.md). *Ways to initiate refunds.* On the merchant's side, refunds can be initiated via the Gate API and Dashboard. When working via the Gate API, to initiate refunds, use the endpoints and formats described in thecorresponding articles: for payments with the direct use of cards, the information is provided in the [Purchase refunds](en_Gate_Refund.md) article; for payments with the alternative methods, the information is provided in the articles about working with these methods in the [Methods](en_pm_about.md) section. When working via Dashboard, use the tools for issuing single and mass refunds described [in the corresponding article](en_dbl_payments.md#). *Other ways to return funds.* Such ways surely exist. In some cases, instead of usual purchases with the subsequent refunds, [two-step purchases](en_gate_payment_auth.md#) can be useful. As a rule, within each two-step purchase, a particular amount is first authorised on the customer's account, and then either only a part of this amount is withdrawn, while the other part is released, or nothing is withdrawn and the funds are fully returned to the customer. Along with that, a significant advantage can be the promptness of the funds' return: that is, a release of funds can take seconds or minutes, while an actual refund can take hours or even days. Besides, in situations when it is required to return funds but refunds are not supported for payment methods in use or cannot be issued due to imposed limitations\(for example, when the refund option is time-restricted for a certain purchase\), you can coordinate with customers and the Ecommpay specialists the processing of corresponding payouts via the payment methods in question or via other payment methods. In such cases, it is important to inform your customers about the indirect return of funds and obtain their consent to reimbursements via payouts.At the same time, the capability of returning funds via payouts can work as a competitive advantage and foster customers' loyalty. Finally, if you come across any other refund-related situations which are not covered in this answer or in the articles mentioned in this answer, you can contact your account manager and mutually search for best solutions, which you will surely find. ## When and how can I reverse refunds and payouts? {#section_hds_lh2_wbc .section} **Short answer:** in specific cases, it is possible to perform reversals of refunds and payouts, which helps to return funds that were mistakenly transferred to customers; the processing of such specialised operations is facilitated through direct engagement with the Ecommpay technical support specialists. **Overview** Occasionally, due to various circumstances, it may be necessary to reverse funds after transferring them as part of a refund or payout—for example, if the refund was made for the wrong purchase or if the payout was made for an excessive amount. The Ecommpay payment platform provides capabilities for cancelling such actions, but only within the limitations imposed by providers and payment systems. **Conditions** - Refunds and payouts can be reversed onlywithin the payment methods that support this capability, taking into consideration any additional restrictions on payment instruments and other criteria. Additional information about such restrictions for card payments is provided in this answer.Information for alternative payment methods can be clarified with the Ecommpay technical support specialists. - When considering time restrictions imposed by providers and payment systems, it is also necessary to consider the time required to reverse a refund or a payout on the Ecommpay side—typically, this process takes no more than thirty minutes. Reversing operations after the specified deadlines may lead to chargebacks, and in such cases, the merchant is responsible for any potential compensation. - Refunds and payouts can be reversed only in relation to those operations and payments that are not disputed by customers. Upon receiving information about chargebacks of incorrectly performed refunds or payouts, it is advisable to accept such chargebacks. For more informations on handling chargebacks, refer [to the relevant FAQ subsection](en_faq_chargebacks.md). - You can reverse only separate `refund` operations. The `reversal` operations can not be cancelled. Also, it is not possible to reverse several `refund` operations with partial refunds for a single purchase at once. Partial refunds, like full ones, can only be reversed individually. - Refunds issued for card payments can be reversed only for cards of particular card networks, with consideration to the specified time limits: - for the American Express cards—within the time period relevant for a particular project\(this period can be clarified with the Ecommpay account manager\); - for the Mastercard cards—within 24 hours; - for the Visa cards—within 30 calendar days. - Card payouts can be reversed only for Visa cards, within one calendar day, and only in exceptional cases established and regulated by the card network. **Reversal procedure** To reverse a refund or a payout, proceed as follows: 1. Find the identifier of the operation \(`operation_id`\) you need to reverse and inform the Ecommpay technical support specialists that a reversal is needed. To find the operation identifier, you can use the payment information tab in the Dashboard interface or a program callback with information about the operation completion. To contact technical support, you can use the Dashboard interface \(with the function **Create ticket to Support** in the payment information tab\)or email \([support@ecommpay.com](mailto:support@ecommpay.com)\). 2. Receive the confirmation that the reversal request has been registered on the Ecommpay side. Each request is automatically registered and assigned an identifier \(`ticket ID`\), which is communicated in the communication email and can be referenced for further inquiries about the request and its progress. 3. Receive a response regarding the outcome of your request. Processing such requests typically takes up to 30 minutes within which the Ecommpay support specialists perform the following: 1. Verify that the target operation is eligible for a reversal according to the card network's rules. 2. If the reversal eligibility is confirmed, perform the necessary actions. For reversing a refund—the `refund_reversal` operation is created and processed as part of the payment for which the refund was made, this operation is assigned the `success` status, while the payment is assigned the `partially refunded` or `success` status\(depending on the actual payment amount that remains\); the status of the refund operation being reversed remains unchanged, and the information about the created operation is displayed in the payment information tab in the Dashboard interface without being sent in program callbacks to the web service. For reversing a payout—this payout is assigned the `decline` status, with no additional operations created, the payment information is updated in the Dashboard interface, while the callback with information about the change of the payout status is sent to web service by prior agreement with the merchant. 3. Communicate the result regarding the outcome of the reversal request. 4. If the target operation has been reversed, ensure the return of funds. After reversing a refund, the balance should increase by the refund amount minus the fee charged by Ecommpay for the reversal, while after reversing a payout, the balance should increase by the payout amount and the fee charged previously by Ecommpay for processing the payout. **Parent topic:**[FAQ](en_faq.md) --- # Callbacks {#en_faq_callbacks} An article with answers to questions about working with callbacks sent from the payment platform. This subsection provides answers to questions about callbacks sent from the payment platform including their parameters and configuration. Callbacks sent from the Ecommpay payment platform to merchants' web services include sets of parameters with information about a payment and the last operation performed within this payment. For more information about standard sets of parameters, see [Handling callbacks](en_platform_callbacks.md#). Along with that, the structures of callbacks can be configured according to merchants' preferences provided that it is coordinated by the Ecommpay technical support specialists. Viewing and changing callback settings is possible only upon request to the Ecommpay technical support specialists. If a callback is not received over the specified period of time, check the following settings: 1. The callback URL is the URL provided to the Ecommpay specialists during integration. 2. The URL is configured correctly to accept HTTP requests from the payment platform—The Ecommpay IP addresses are in the whitelist and are not blocked by the firewall or other network devices. 3. The payment request enables the function for sending callbacks—that is to say, it does not contain the parameter `callback.force_disable` with value `1`. If this does not help, and callbacks are still not received, contact the Ecommpay technical support specialists. Make sure you provide the project ID and the corresponding callback URL. **Parent topic:**[FAQ](en_faq.md) --- # Results {#en_faq_payment_result} An article with answers to questions about monitoring and interpreting results of payments, operations, and procedures performed within the platform. This subsection provides answers to questions about control and interpretation of different payment results, operations, and procedures performed within the platform. For this, both user and programming interfaces can be used. But keep in mind that the information in the user interfaces can be delayed \(usually for up to a minute\), while the programming interfaces allow to get this information without a delay \(as soon as the messages are formed and transmitted\). If obtaining information via the user interfaces is preferred, you can refer to the payment registers and payment information tabs in the Dashboard interface \(for more information, see [Monitoring payment processing](en_dbl_payments.md#) for Dashboard\). If obtaining information via the programming interfaces is preferred, you can use callbacks sent from the platform in certain cases and responses to the requests for the payment status information. These callbacks and responses can contain the object `payment` and the arrays `operations` and `errors` with such parameters as `status`, `code`, and `message`\(for more information, see [Handling callbacks](en_platform_callbacks.md#) and [Checking current payment information](en_Gate_payment_status_request.md#)\). When it comes to working with the Gate API, keep in mind that synchronous responses sent to requests processed according to the asynchronous model of interaction use the `status` parameter in the body to indicate the status of a request, not a payment or operation. The `success` status in the request body indicates that the request has been accepted for processing, while the `error` status means that it is impossible to process and execute the request.For more information about these statuses, responses, and their general structure, see the [Response format](en_gate_interaction_organisation.md#). In order to get the information about the statuses of payments and operations, see the `status` parameter in the corresponding objects `payment` and `operation` in callbacks and responses to payment status requests or use Dashboard. For more information about payment and operation results, see [How do I check the status of a payment or an operation?](en_faq_payment_result.md#fig_yt1_tth_smb). In some cases, the actual transfer of funds on the side of payment systems can be carried out with a delay \(up to several days\) after the operation is confirmed and receives its final status. Thus, if you have questions about discrepancies between flow of funds and the status of a payment or operation, consult the Ecommpay technical support specialists or contact the providers and payment systems to get the status of a specific payment. If there are errors or rejections during request processing or operation performing, you can learn the reason: - in a synchronous response to a request—in case of an error during the initial request processing.For more information about these errors, see the [Response format](en_gate_interaction_organisation.md#) section. - in an intermediate or final callback—through a response code and a message which are passed: - in the `errors` array—if the operation was rejected in the payment platform \(for example, it failed the established business rules validation\); - in the `operation.code` and `operation.message` parameters—if the operation was rejected bya provider or payment system. For more information about working with callbacks, see [Handling callbacks](en_platform_callbacks.md#). - in the payment information tabs in the Dashboard interface. For more information about working with registers and payment information tabs, see the [Monitoring payment processing](en_dbl_payments.md#) section. For more information about possible errors during operation processing and the codes which are passed in callbacksand displayed in the Dashboard interface, see information [Handling operation processing information](en_platform_payment_info_codes.md). **Parent topic:**[FAQ](en_faq.md) --- # Chargebacks {#en_faq_chargebacks} An article with answers to questions about working with chargebacks on payments processed via the payment platform, largely in cases when Ecommpay acts as an acquirer. This subsection provides answers to questions about working with chargebacks on financial operations.Some parts of the information here are general and applicable to chargebacks as a whole, but most parts of the information apply to payments in the context of which Ecommpay acts as an acquirerand, in cases of chargebacks, interacts with issuers and card networksrepresenting the merchant's interests. These payments are the ones processed with the use of the Mastercard and Visa cards in the scope of card paymentsand payments made via the Apple Pay and Google Pay payment methods. ## A chargeback and a dispute—what do these terms mean? {#section_pfj_2xr_q5b .section} **Short answer:** these are different options to define the regulated process of disputing a financial operation. A *chargeback* is a regulated process of disputing a financial operation in order to return its full or partial amount. Within the work with different card networks, this procedure can be defined by different terms: for example, the Mastercard global card network uses the term *chargeback*, while the Visa global card network refers to the procedure as a *dispute*. In the context of the Ecommpay payment platform, the general term *chargeback* is used. Chargebacks can be filed on the customers' or issuers' initiative to dispute separate operations that result in: - debiting of funds from the customers' accounts within purchases, - returning the funds after purchases, - crediting of funds within payouts. Chargebacks can occur for various reasons, for example, when a customer is unhappy with the service quality or an issuer is unable to credit a customer's account for technical reasons. **Note:** One of the chargeback reasons can be processing an operation with the authorisation declined by the issuer \(here authorisation means the issuer's approval of processing a purchase or a payout with the use of a certain payment card\). Within the Ecommpay payment platform, unauthorised operations cannot be processed technically for the following reason: an authorisation request is automatically sent to the issuer's service upon the receipt of a payment request from the merchant's web service, and if the issuer declines to authorise the operation, the payment is also declined on the payment platform side. However, this does not eliminate the possibility of chargebacks related to the authorisation issues. Chargebacks can affect the merchant's business reputation and lead to extra costs, thus it is important to respond to each chargeback quickly and resolve it in accordance with the card network rules. To ensure compliance with these conditions for its merchants,Ecommpay is actively involved in managing chargebacks on operations in the context of which Ecommpay acts as an acquirer. These operations are the onesprocessed with the use of the Mastercard and Visa cards in the scope of card paymentsand payments made via the Apple Pay and Google Pay payment methods. When chargebacks on such operations occur, Ecommpay notifies the merchants about new chargeback information in a timely manner and, when necessary, creates response documents for challenging chargebacks based on the pieces of evidence provided by the merchants and according to the card networks rules, then sends these documents to the issuers and accompanies the process until its completion. For more information about the chargeback process, see the answer to the corresponding question of this section—[How is the chargeback process organised?](en_faq_chargebacks.md#section_ppz_lhs_q5b) ## What should I do upon receiving a chargeback? {#section_kl1_jzr_q5b .section} **Short answer:** upon receiving the chargeback information from Ecommpay, the merchant should either accept or challenge the chargeback via the Dashboard interface within four business days following the day of the chargeback information receipt. *What should be done.* After the information about a new chargeback is received, the notification about it is displayed in the Dashboard interface and sent to the merchant via emailas well as through a callback, if this feature has been configured \([details](en_dbl_chargeback_callbacks.md#)\).Depending on whether the merchant agrees or disagrees with the chargeback, the merchant can either *accept or challenge* it.If the chargeback is accepted, the chargeback process finishes in favour of the issuer. If the chargeback is challenged, the process continues until one of the parties accepts the liability or the card network arbitration committee makes a decision. **Note:** In the Dashboard interface, chargebacks are grouped into cases according to the parameters **Report date**, **Account number**, and **Reason code**. This allows providing response to a separate chargeback or to several ones included in the case. In the chargeback information tab, the left panel contains the list of all chargebacks under the case, the two middle panels contain the information about the selected chargeback, and the right panel contains the details by which the chargebacks were grouped. *What should be considered.* If the arbitration committee steps in, then, if the merchant loses or accepts the chargeback, the merchant is considered liable not only for the amount of the disputed operation but also for the fee amount charged by the card network. This is why, beforechallenging a chargeback, the merchant should *ensure they have the necessary evidence* for supporting their position and countering the chargeback. The information as to which documents may be required for challenging chargebacks in certain cases and recommendations for preparing such documents is provided in the chargeback information tabs of the Dashboard interface\(on the panel for providing evidence\) or can be requested from the Ecommpay chargeback specialistsvia email \(add your account manager as one of the recipients\).Along with that, in certain cases, providing documents can be unnecessary: for example, if the chargeback reason concerns processing an operation without authorisation performed, specifying the authorisation code and date will suffice. In case of chargebacks filed due to fraud issues and on operations that have not been refunded, arbitration committees can make their decisions based on the 3‑D Secure authentication result codes \(for more information, see the [Electronic Commerce Indicators](en_ECI_codes.md) reference\): in such cases, if according to the code value, the merchant is the responsible party, the decision is usually made in favour of the issuer. Thus, before the merchant makes a decision on a chargeback, it is recommended to first *check the ECI* of the disputed operation. *When chargeback decisions should be made.* The merchant should provide all decisions on the chargeback *within the periods stipulated by Ecommpay*. The initial response to the chargeback should be provided within four business days following the day of the chargeback information receipt. For further responses, the response period can vary: in case of Visa and chargebacks related to the authorisation and fraud issues, the response period can be from one to two business days, while in other cases this period averages about four business days. If the merchant makes no action before the stipulated deadline, the chargeback process finishes in favour of the issuer or continues until the arbitration committee makes a decision \(if the issuer has already submitted the chargeback to the committee\). **Note:** The information about the periods allocated for merchants to make decisions is provided in the chargeback information tabs of the Dashboard interface or—if upon coordination with Ecommpay, the merchant does not use Dashboard accounts—in the notifications sent by the Ecommpay specialists to the specified email address of the merchant. *How chargeback decisions should be communicated.* Technically, a chargeback can be accepted or challenged *via the **Chargebacks** section* of the Dashboard interface\(the following tools of the chargeback information tab can be used: **Accept**, for accepting the chargeback, and **Submit Evidence**, for challenging the chargeback\) or, if for some reason the response cannot be provided via Dashboard, *by contacting* the Ecommpay chargeback specialists\(their email address is provided in the chargeback information tab or can be requested from your account manager\). *How emerging questions should be addressed.* If you have questions about working with chargebacks, contact the Ecommpay account manager and chargeback specialists\(adding your account manager as one of the recipients\). ## How is the chargeback process organised? {#section_ppz_lhs_q5b .section} **Short answer:** each chargeback process is carried out in stages and according to one of the chargeback workflows, where Ecommpay, as an acquirer, represents the merchant's interests interacting with the card network and the issuer. **Overview** The following three parties are usually involved in the chargeback process—the issuer from the customer side, the card network as a regulatory body, and the acquirer or the merchant from the merchant side. Ecommpay works with chargebacks on the operations in the context of which Ecommpay acts as an acquirer. These operations are the onesprocessed with the use of the Mastercard and Visa cards in the scope of card paymentsand payments made via the Apple Pay and Google Pay payment methods.In cases of chargebacks on such operations, Ecommpay, within the established timelines, interacts with all parties and, notifies the merchant about the issuer's and card network's decisions, while also ensuring the required flow of the merchant's funds. In other cases—regarding chargebacks on operations processed via the Ecommpay payment platform by using cards of other card networks or via other alternative payment methods—the merchant works with chargebacks on their own. Chargebacks on financial operations can be processed with regard to the transitions between different stages, and the number of the stages can vary depending on the card network, chargeback reason, and the decisions made by the parties. Ecommpay uses four stages of the chargeback process—Chargeback, Representment, Pre-Arbitration \(which includes the *attempt* and *response* steps\), and Arbitration. When the information about a new chargeback is received by Ecommpay, this information is registered in the platform and becomes available via the Dashboard \(in the **Chargebacks** section\)and Data API\([details](en_dbl_using_api.md#)\) interfaces with the automatic notification sent to the specified email addresses of the Dashboard accounts \(for which the **Receive e-mails about chargebacks** function is enabled in the user profiles\). At the same time, the first chargeback stage—Chargeback—opens. **Note:** If, as agreed with Ecommpay, the merchant does not use any Dashboard account, the notification about a new chargeback is sent to the specified email address of the merchant, and this notification contains the file with full chargeback information. After reviewing the chargeback information, the merchant can *accept* or *challenge* the chargeback. If the chargeback is accepted, the chargeback process finishes in favour of the issuer; if the chargeback is challenged, the chargeback process continues until one of the parties makes a final decision. **Note:** If chargebacks on refunds and chargebacks on payouts occur, it is recommended to accept such chargebacks, since they are usually filed due to the issuers' inability to credit the funds to the customers' accounts and challenging these chargebacks does not solve this problem.Upon receiving chargebacks on refunds and payouts, the merchant can contact the customers and suggest that they address the issuers to identify the reasons why the funds are not credited to their accounts and to find the possibilities of retrying crediting of funds. If there are no such possibilities on the issuers' side, it is recommended to find other ways of transferring the funds to the customers. At the Representment and Pre-Arbitration stages, the parties exchange additional details, consider each other's arguments, and try to find an agreed solution. If the parties do not reach a mutual solution, at the final stage of the chargeback process—Arbitration—the arbitration committee steps in.In this case, the party that loses the chargeback by the committee's decision is held responsible for paying not only the disputed amount but also the card network fee. **Chargeback workflows** Within the interaction with separate card networks, the chargeback process can be organised in different ways. For this,Ecommpay uses *one full and two shortened workflows*. The full workflow includes all chargeback stages andis used in the following cases: - For Mastercard chargebacks, except the ones managed within the short workflow. - For Visa chargebacks that occur due to operation processing errors or consumer disputes \(which cover such issues as goods and service quality or crediting of funds to the customer's account\). The shortened workflows, depending on a card network, do not include certain stages and are used in the following cases: - For Mastercard chargebacks due to authorisation issues, when the issuer submits the chargeback for the arbitration committee review following the results of the Representment stage. In this case, the Pre-Arbitration stage is not initiated. - For Visa chargebacks that occur due to authorisation issues or fraud. In this case, the Representment stage is not initiated and the initial response to the chargeback with the merchant's evidence is provided at the Pre-Arbitration stage. Considering these special aspects, the chargeback process workflows in the Ecommpay payment platform can be illustrated as follows. ![](images/en_chargeback_mastercardvisa.svg) *Full workflow* ![](images/en_chargeback_mastercard.svg) *Shortened Mastercard workflow* ![](images/en_chargeback_visa.svg) *Shortened Visa workflow* **Chargeback stages** *Overview* Each stage of the chargeback process is initiated and managed in a certain way. Depending on a stage and its outcome, different situations can occur.The following paragraphs describe such situations and provide information about the changes of chargeback status and the merchant's balance \(in case of chargebacks on refunds and payouts, the merchant's balance changes in reverse\). *Chargeback* The Chargeback stage is initiated by the issuer and the responsibility for responding at this stage lies on the merchant \(excluding the situation when the issuer withdraws the chargeback\).At this stage, *the merchant should provide Ecommpay with the decision on the chargeback* no later than four business days following the day of the chargeback information receipt. Along with that, depending on the situation and evidence at hand, the merchant can dispute the initial amount of the chargeback fully or partially. Generally, at the Chargeback stage, the following situations can occur. |Situation|Status| |---------|------| |The chargeback information has been received by Ecommpay and sent to the merchant. The response is awaited—the merchant can either accept or challenge the chargeback. The merchant's balance decreases by the initial amount of the chargeback. Along with that, the merchant can be charged a fee of Ecommpay. |Needs response| |The chargeback has been accepted by the merchant because the merchant either has decided to accept it or has not responded to it within the stipulated period\(in the latter case, the *expired* marker is used next to the status\). The chargeback process is completed in favour of the issuer. The merchant's balance remains unchanged. |Accepted by merchant| |The chargeback has been withdrawn by the issuer.The chargeback process is completed in favour of the merchant. The merchant's balance increases by the initial amount of the chargeback. |Cancelled by issuer| |The chargeback has been disputed by the merchant.Ecommpay initiates the next stage. The merchant's balance remains unchanged. |In progress| *Representment* Within the full \(Mastercard and Visa\) workflow and the short Mastercard workflow, the Representment stage is initiated by Ecommpay and the responsibility for responding at this stage lies on the issuer. Within the short Visa workflow, this stage is never initiated and the chargeback is first challenged at the Pre-Arbitration stage.At the Representment stage, Ecommpay, via the card network, sends the merchant's evidence to the issuer and *the merchant should wait for the information about the issuer's decision*. At the Representment stage, the following situations can occur. |Situation|Status| |---------|------| |The chargeback has been challenged \(fully or partially\) and the merchant's evidence has been provided. The issuer's response is awaited—the issuer can either accept the evidence or continue the chargeback process. The merchant's balance remains unchanged. |In progress| |The merchant's evidence provided for partially challenging the chargeback has been accepted by the issuer.The chargeback process is completed partially in favour of the merchant and partially in favour of the issuer. The merchant's balance increases by a part of the initial amount of the chargeback, since the merchant was charged the total initial amount of the chargeback at the Chargeback stage. |Partially won| |The merchant's evidence has been accepted by the issuer.The chargeback process is completed in favour of the merchant. The merchant's balance increases by the initial amount of the chargeback. |Won| |The merchant's evidence has not been accepted by the issuer or has been accepted only partially.The issuer initiates the next stage. The merchant's balance remains unchanged |In progress| *Pre-Arbitration* The Pre-Arbitration stage consists of the two steps: attempt and response at which Ecommpay and the issuer inform each other about the decisions on the chargeback in the order that depends on the chargeback workflow. Along with that, the amount being disputed can be decreased by the issuer if they accept only a piece of the merchant's evidence. Within the full workflow, the Pre-Arbitration attempt is initiated by the issuer \(if the issuer did not accept the merchant's evidence at the Representment stage\) and the responsibility for making a decision at the Pre-Arbitration response step lies on the merchant. In this case, *the merchant should notify Ecommpay about their decision* on the chargeback within the stipulated period which on average can be about four business days following the day when the merchant is notified about the attempt step initiation. Within the short Mastercard workflow, this stage is never initiated, since the issuer decides to submit the chargeback to the arbitration committee as a result of the Representment stage. Within the short Visa workflow, the Pre-Arbitration attempt step is initiated by Ecommpay and the responsibility for making decisions at the Pre-Arbitration response step lies on both the issuer and the merchant. In this case, if the issuer has not accepted the merchant's evidenceat the Pre-Arbitration response step, *the merchant should notify Ecommpay about their decision* on further actions—either to accept the chargeback or to submit it to the arbitration committee of the card network. As a rule, the decision should be provided within the stipulated period which can be from one to two business days following the day when the merchant is notified about the issuer's decision. **Note:** The information about the periods allocated for merchants to make decisions is provided in the chargeback information tabs of the Dashboard interface or—if upon coordination with Ecommpay, the merchant does not use Dashboard accounts—in the notifications sent by the Ecommpay specialists to the specified email address of the merchant. Within the full workflow, at the Pre-Arbitration stage, the following situations can occur. |Full workflow. Situation|Status| |------------------------|------| |*Pre-Arbitration attempt*| |The evidence provided at the Representment stage, has not been accepted by the issuer or has been accepted only partially. The information about it has been sent to the merchant. The response is awaited—the merchant can either accept or challenge the chargeback. The merchant's balance remains unchanged |In progress| |*Pre-Arbitration response*| |The merchant's response has been received\(or the period allocated for providing the response has expired and the chargeback becomes accepted\). The merchant's balance remains unchanged. |In progress| |The chargeback has been accepted by the merchant.The chargeback process is completed in favour of the issuer. The merchant's balance remains unchanged, since the merchant was already charged the amount of the disputed operation at the Chargeback stage. |Accepted by merchant| |The chargeback has been challenged by the merchant. The issuer's response is awaited—the issuer can either accept the evidence or submit the chargeback to the arbitration committee of the card network. The merchant's balance remains unchanged. |In progress| |The merchant's evidence has been partially accepted by the issuer and the merchant has agreed with this decision.The chargeback process is completed partially in favour of the merchant and partially in favour of the issuer. The merchant's balance increases by a part of the disputed amount, since the merchant was charged the initial amount of the chargeback at the Chargeback stage. |Partially won| |The chargeback has been challenged by the merchant and theevidence has been accepted by the issuer. The chargeback process is completed in favour of the merchant. The merchant's balance increases by the amount of the disputed operation. |Won| |The chargeback has been challenged by the merchant and theevidence has not been accepted by the issuer. The submission of the chargeback to the card network arbitration committee is awaited\(this submission is performed by the issuer\). The merchant's balance remains unchanged. |In progress| Within the short Visa workflow, at the Pre-Arbitration stage, the following situations can occur. |Short Visa workflow. Situation|Status| |------------------------------|------| |*Pre-Arbitration attempt*| |The chargeback has been challenged and the merchant's evidence has been provided. The issuer's response is awaited—the issuer can either accept the evidence or continue the chargeback process. The merchant's balance remains unchanged. |In progress| |*Pre-Arbitration response*| |The issuer's response has been received. The merchant's balance remains unchanged. |In progress| |The merchant's evidence has been partially accepted by the issuer and the merchant has agreed with this decision.The chargeback process is completed partially in favour of the merchant and partially in favour of the issuer. The merchant's balance increases by a part of the disputed amount, since the merchant was charged the initial amount of the chargeback at the Chargeback stage. |Partially won| |The evidence has been accepted by the issuer.The chargeback process is completed in favour of the merchant. The merchant's balance increases by the initial amount of the chargeback. |Won| |The evidence has not been accepted by the issuer. The merchant's response is awaited—the merchant can decide either to accept the chargeback or to submit it to the arbitration committee. The merchant's balance remains unchanged. |In progress| |The chargeback has been accepted by the merchant or the merchant has not provided the response within the stipulated period.The chargeback process is completed in favour of the issuer. The merchant's balance remains unchanged, since the merchant was already charged the initial amount of the chargeback at the Chargeback stage. |Accepted by merchant| |The chargeback is challenged by the merchant. The submission of the chargeback to the card network arbitration committee is awaited\(this submission is performed by Ecommpay\). The merchant's balance remains unchanged. |In progress| *Arbitration* Within the full \(Mastercard and Visa\) workflow and the short Mastercard workflow, the Arbitration stage is initiated by the issuer \(in this case, the Ecommpay chargeback specialists inform the merchant that this stage has been initiated\), while within the short Visa workflow, the Arbitration stage is initiated by Ecommpay upon coordination with the merchant. The responsibility for making a decision at this stage lies on the card network arbitration committee.At this stage, *the merchant should wait for the decision* of the arbitration committee. The arbitration committee starts the chargeback consideration after the preparatory period expires—this period is seven and ten calendar days in case of Visa and Mastercard accordingly. Within this period and until the arbitration committee rules on the case, the merchant can ask Ecommpay to withdraw the chargeback. The merchant, however, should bear in mind that this withdrawal leads to the acceptance of the chargeback and the card network fee charges applied for losing the chargeback.At the same time, before the final decision is made, the issuer can also terminate the chargeback process by accepting the provided evidence. When examining the chargeback, the arbitration committee considers only the amount of the chargeback that remains unresolved between the merchant and the issuer at the Arbitration stage. For example, if the initial disputed amount of 900 USD was decreased to 600 USD on the merchant's or the issuer's initiative in the course of the dispute, then at the Arbitration stage, the amount of 600 USD will be considered and reimbursed in favour of one of the parties or divided between them by the decision of the card network's arbitration committee. As a result of the Arbitration stage, the merchant can be charged the card network fees in the following cases: - If Ecommpay withdraws the chargeback on the merchant's request. - If the decision is made in favour of the issuer \(even partially\). - If violations on the merchant side are detected \(such violations can be, in particular, the violations of the card network rules regarding the usage of the customer payment credentials\). **Note:** For more information about the fees charged by the card networks in certain cases and possible violations for which fees are applied, contact the Ecommpay chargeback specialists via email \(by adding your account manager as one of the recipients\). The email address of the chargeback specialists is provided in the chargeback information tabs of the Dashboard interface. In general, at the Arbitration stage, the following situations can occur. |Situation|Status| |---------|------| |The arbitration committee's decision is awaited.At the same time, the chargeback can be withdrawn on the merchant's or the issuer's request before the committee makes a decision. The merchant's balance remains unchanged. |In progress| |The chargeback has been withdrawn on the merchant's requestbefore the arbitration committee rules on it. The chargeback process is completed in favour of the issuer. The merchant's balance decreases by the amount of the card network fee, since the merchant was already charged the initial amount of the chargeback at the Chargeback stage. |Accepted by merchant| |By the arbitration committee's decision, the chargeback process has been completed in favour of the issuer. The merchant's balance decreases by the amount of the card network fee, since the merchant was already charged the initial amount of the chargeback at the Chargeback stage. |Lost| |By the arbitration committee's decision, the chargeback process has been completed partially in favour of the merchant and partially in favour of the issuer. The merchant's balance increases by a part of the disputed amount, since the merchant was charged the total disputed amount at the Chargeback stage. Along with that, the amount of the card network fee, depending on the arbitration committee's decision, can be charged either to one of the parties or divided between them. |Partially won| |The chargeback has been withdrawn on the issuer's request, by the arbitration committee's decision, the chargeback process has been completed in favour of the merchant. The merchant's balance increases by the disputed amount. |Won| ## How can I check the chargeback status? {#section_t22_s5q_n5b .section} **Short answer:** information about chargebacks that are processed with Ecommpay involved can be obtained via the Dashboard and Data API interfaces, and, in certain cases, via email. Relevant information about chargebacks, as well as about the chargeback statuses, can be obtained via Dashboard\(by using the **Chargebacks** and **Reports** sections\) and the Data API\([details](en_dbl_using_api.md#)\). Additionally, the chargeback information can be sent by the Ecommpay specialists to the specified email address of the merchant in the following cases: - When the merchant, upon coordination with Ecommpay, does not use Dashboard accounts. - When the chargeback is submitted to the arbitration committee. - When the chargeback process is completed because the arbitration committee has made the decision in favour of the issuer \(fully or partially\). The following statuses are assigned to the chargebacks in the Ecommpay payment platform. |Needs response|Intermediate status. The merchant's response to the chargeback is awaited.| |In progress|Intermediate status. The work with the chargeback is in process, the final decision has not been made yet.| |Accepted by merchant \(expired\)|Final status. The merchant has not responded within a stipulated period. The chargeback process is completed in favour of the issuer.| |Accepted by merchant|Final status. The merchant has accepted the chargeback. The chargeback process is completed in favour of the issuer.| |Lost|Final status. The arbitration committee has made the decision in favour of the issuer.The chargeback process is completed in favour of the issuer.| |Partially won|Final status. The chargeback process is completed partially in favour of the merchant and partially in favour of the issuer for one of the following reasons: ◆ The merchant has challenged a part of the initial chargeback amount and the issuer has accepted the merchant's evidence. ◆ The merchant's evidence provided for challenging the initial chargeback amount has been partially accepted by the issuer and the merchant agreed with this decision. ◆ The arbitration committee has made the decision partially in favour of each party. | |Won|Final status. The issuer has accepted the evidence or the arbitration committee has made the decision in favour of the merchant. The chargeback process is completed in favour of the merchant.| |Cancelled by issuer|Final status. The issuer has withdrawn the chargeback.The chargeback process is completed in favour of the merchant.| ## What is a chargeback reversal? {#section_t4k_dn5_p5b .section} **Short answer:** this term refers to the situations when the issuer withdraws the chargeback. A *chargeback reversal* is a chargeback withdrawal initiated by the issuer before the merchant provides the initial response to this chargeback.As a result of such withdrawal, the merchant's balance increases \(if the chargeback was filed on a purchase\) or decreases \(if the chargeback was files on a refund or a payout\) by the initial chargeback amount and the chargeback gets the Cancelled by issuer status. The merchant is not required to respond to the chargeback in this case. ## A chargeback on refund and a chargeback on payout—what do these terms mean? {#section_ps1_3rp_w5b .section} **Short answer:** these terms refer to the chargebacks filed on the operations of refunds and payouts. A *chargeback on refund* and a *chargeback on payout* refer to the procedures of disputing a refund and a payout accordingly. These chargebacks are filed by issuers when the issuers are not able to credit funds to the cardholders' accounts\(for example, due to these accounts' closure or region-specific requirements\). As a result of such chargebacks, the fundsthat were previously taken from the merchant within refunds and payouts are returned to the merchant. Since the reasons for such chargebacks are defined only on the issuers' side, the merchants cannot prevent these situations.However, in such cases, the merchant can contact the customers and suggest that they address the issuers to identify the reason why the funds are not credited to their accounts and to find the opportunities of retrying the crediting of funds. If there are no such opportunities on the issuers' side, it is recommended to find other ways of transferring the funds to the customers. ## Is it possible to prevent a chargeback on a purchase by refunding the purchase and why the issuers can file chargebacks even after refunds? {#section_ibr_wrp_w5b .section} **Short answer:** refunds do help prevent chargebacks but not to the full extent, since, in some cases, the issuers can have reasons to dispute purchases even after these purchases have been refunded. Promptly returning the funds to the customer when an unreasonable withdrawal is detected\(for example, when the customer complains they have not received the goods or services they paid for\) can help to prevent a disputable situation but still does not eliminate the possibility of a chargeback.If, regardless of a refund, the issuer has filed a chargeback on a purchase, the evidence that the refund was made can be used by the merchant for challenging the chargeback. This increases the merchant's chance of winning the chargeback, although it does not guarantee it. An issuer can file a chargeback for a payment that has been already refunded for different reasons, including the following ones: - The funds have not been credited to the cardholder's account yet and the issuer does not know about the initiated refund. After a refund, the funds should be credited to the cardholder's account within a period stipulated by the card network \(usually this period is up to 15 calendar days\). However, the customer can address a claim to the issuer before the funds are returned and the issuer can file a chargeback due to the absence of the refund information. - The correlation between the operation and refund could not been found. The issuer can check the cardholder's account information and not match the refund with the purchase for one of the following reasons: - Several purchases with different amounts were processed and a refund was made for one of these purchases. - The amount of the purchase does not match that of the refunddue to different exchange rates on the date of payment processing and the date of refund processing. - The issuer has decided the refund is not related to the disputed operation.In this case, the issuer should explain the reasons for this decision. In order to prevent such situations, it is important to inform customers about the payment status, refund policy and timelines.If the chargeback was filed regardless of the previously made refund, it is recommended to respond to the chargeback providing Ecommpay with the evidence of the refund. For additional consultations on steps that can be taken in such cases, contact the account manager or chargeback specialists of Ecommpay. \(The email address of the chargeback specialists can be found in the chargeback information tabs of the Dashboard interface or requested from your account manager. When contacting the chargeback specialists, specify the account manager as one of the recipients.\) ## Should I make a refund for the operation being disputed? {#section_rl3_xhk_x5b .section} **Short answer:** it is not recommended to refund an operation that is being disputed. Generally, after a chargeback has been filed on a purchase, it is not recommended to refund this purchase for the following reason. After the information about a new chargeback has been received by Ecommpay,regardless of the merchant's decision \(to accept or challenge this chargeback\), the merchant's balance decreases by the initial chargeback amount and this amount is returned to the issuer, and then \(if the issuer wins the chargeback\) to the customer. Thus, if the merchant attempts to make a refund for the disputed operation, this refund is declined automatically on the platform side—in order to avoid double return of funds. With that, If despite the risk of double return of funds, the merchant still has questions about refunds for a disputed operation, these questions can be directed to the Ecommpay account manager. **Parent topic:**[FAQ](en_faq.md) --- # References {#en_directory} A section with the glossary and the reference information relevant to working with the platform. This section includes the glossary of terms used in the documentation and the reference information about the language and currency codes,the identifiers of payment methods supported in the Payment Page and Dashboard interfaces, the countryand region codes, and the Electronic Commerce Indicators. - [Glossary](en_glossary.md#) - [Language codes](en_language_codes.md) - [Currency codes](en_currency_codes.md) - [Payment method codes](en_pm_codes.md) - [Payment card codes](en_card_codes.md) - [Country codes](en_country_codes.md) - [Region codes for card payments](en_region_codes.md) - [Test cards](en_test_cards.md) - [Electronic Commerce Indicators](en_ECI_codes.md) - **[Glossary](en_glossary.md#)** A glossary of terms used in the platform and the documentation. - **[Language codes](en_language_codes.md)** A reference with the language codes in the alpha-2 format of the ISO 639 standard. - **[Currency codes](en_currency_codes.md)** A reference with the currency codes in the alpha-3 format of the ISO 4217 standard. - **[Payment method codes](en_pm_codes.md)** A reference with the internal codes of supported payment methods relevant to working with different interfaces of the platform. - **[Payment card codes](en_card_codes.md)** A reference with the internal codes indicating the payment card brands that can be used for working with the platform. - **[Country codes](en_country_codes.md)** A reference with the country codes in the alpha-2 format of the ISO 3166-1 standard. - **[Region codes for card payments](en_region_codes.md)** A reference with the region codes used in processing Mastercard and Visa payments via Ecommpay. - **[Test cards](en_test_cards.md)** A reference with card numbers that can be used for testing different card payment scenarios. - **[Electronic Commerce Indicators](en_ECI_codes.md)** A reference with the Electronic Commerce Indicators used by different card networks to communicate the results of the 3‑D Secure authentication of customers. --- # Language codes {#en_language_codes} A reference with the language codes in the alpha-2 format of the ISO 639 standard. When working with various interfaces of the Ecommpay payment platform, you may need to use short letter codes for language names. For example, to open Payment Page in a specific language, you have to submit a request with the code of this language specified \([learn more](en_PP_WigetLanguages.md#section_ivb_h3b_sqb)\). In general, we use two-letter language codes defined in the [ISO 639](https://www.iso.org/iso-639-language-codes.html) standard, but if there is a need for the languages not included in this standard, you should contact us to discuss the use of additional language codes. The following table contains the language codes in the alpha-2 format of the ISO 639 standard. |Code|Language| |:--:|--------| |`aa`|Afar| |`ab`|Abkhazian| |`ae`|Avestan| |`af`|Afrikaans| |`ak`|Akan| |`am`|Amharic| |`an`|Aragonese| |`ar`|Arabic| |`as`|Assamese| |`av`|Avaric| |`ay`|Aymara| |`az`|Azerbaijani| |`ba`|Bashkir| |`be`|Belarusian| |`bg`|Bulgarian| |`bh`|Bihari languages| |`bi`|Bislama| |`bm`|Bambara| |`bn`|Bengali| |`bo`|Tibetan| |`br`|Breton| |`bs`|Bosnian| |`ca`|Catalan, Valencian| |`ce`|Chechen| |`ch`|Chamorro| |`co`|Corsican| |`cr`|Cree| |`cs`|Czech| |`cu`|Church Slavic, Church Slavonic, Old Church Slavonic, Old Slavonic, Old Bulgarian| |`cv`|Chuvash| |`cy`|Welsh| |`da`|Danish| |`de`|German| |`dv`|Divehi, Dhivehi, Maldivian| |`dz`|Dzongkha| |`ee`|Ewe| |`el`|Greek \(modern\)| |`en`|English| |`eo`|Esperanto| |`es`|Spanish, Castilian| |`et`|Estonian| |`eu`|Basque| |`fa`|Persian| |`ff`|Fulah| |`fi`|Finnish| |`fj`|Fijian| |`fo`|Faroese| |`fr`|French| |`fy`|Western Frisian| |`ga`|Irish| |`gd`|Gaelic, Scottish Gaelic| |`gl`|Galician| |`gn`|Guarani| |`gu`|Gujarati| |`gv`|Manx| |`ha`|Hausa| |`he`|Hebrew \(modern\)| |`hi`|Hindi| |`ho`|Hiri Motu| |`hr`|Croatian| |`ht`|Haitian, Haitian Creole| |`hu`|Hungarian| |`hy`|Armenian| |`hz`|Herero| |`ia`|Interlingua, Occidental| |`id`|Indonesian| |`ie`|Interlingue| |`ig`|Igbo| |`ii`|Sichuan Yi, Nuosu| |`ik`|Inupiaq| |`io`|Ido| |`is`|Icelandic| |`it`|Italian| |`iu`|Inuktitut| |`ja`|Japanese| |`jv`|Javanese| |`ka`|Georgian| |`kg`|Kongo| |`ki`|Kikuyu, Gikuyu| |`kj`|Kuanyama, Kwanyama| |`kk`|Kazakh| |`kl`|Kalaallisut, Greenlandic| |`km`|Central Khmer| |`kn`|Kannada| |`ko`|Korean| |`kr`|Kanuri| |`ks`|Kashmiri| |`ku`|Kurdish| |`kv`|Komi| |`kw`|Cornish| |`ky`|Kirghiz, Kyrgyz| |`la`|Latin| |`lb`|Luxembourgish, Letzeburgesch| |`lg`|Ganda| |`li`|Limburgan, Limburger, Limburgish| |`ln`|Lingala| |`lo`|Lao| |`lt`|Lithuanian| |`lu`|Luba-Katanga| |`lv`|Latvian| |`mg`|Malagasy| |`mh`|Marshallese| |`mi`|Maori| |`mk`|Macedonian| |`ml`|Malayalam| |`mn`|Mongolian| |`mr`|Marathi| |`ms`|Malay| |`mt`|Maltese| |`my`|Burmese| |`na`|Nauru| |`nb`|Norwegian Bokmål| |`nd`|North Ndebele| |`ne`|Nepali| |`ng`|Ndonga| |`nl`|Dutch, Flemish| |`nn`|Norwegian Nynorsk| |`no`|Norwegian| |`nr`|South Ndebele| |`nv`|Navajo, Navaho| |`ny`|Chichewa, Chewa, Nyanja| |`oc`|Occitan| |`oj`|Ojibwa| |`om`|Oromo| |`or`|Oriya| |`os`|Ossetian, Ossetic| |`pa`|Panjabi, Punjabi| |`pi`|Pali| |`pl`|Polish| |`ps`|Pashto, Pushto| |`pt`|Portuguese| |`qu`|Quechua| |`rm`|Romansh| |`rn`|Rundi| |`ro`|Romanian, Moldavian, Moldovan| |`ru`|Russian| |`rw`|Kinyarwanda| |`sa`|Sanskrit| |`sc`|Sardinian| |`sd`|Sindhi| |`se`|Northern Sami| |`sg`|Sango| |`si`|Sinhala, Sinhalese| |`sk`|Slovak| |`sl`|Slovenian| |`sm`|Samoan| |`sn`|Shona| |`so`|Somali| |`sq`|Albanian| |`sr`|Serbian| |`ss`|Swati| |`st`|Southern, Sotho| |`su`|Sundanese| |`sv`|Swedish| |`sw`|Swahili| |`ta`|Tamil| |`te`|Telugu| |`tg`|Tajik| |`th`|Thai| |`ti`|Tigrinya| |`tk`|Turkmen| |`tl`|Tagalog| |`tn`|Tswana| |`to`|Tongan \(Tonga Islands\)| |`tr`|Turkish| |`ts`|Tsonga| |`tt`|Tatar| |`tw`|Twi| |`ty`|Tahitian| |`ug`|Uighur, Uyghur| |`uk`|Ukrainian| |`ur`|Urdu| |`uz`|Uzbek| |`ve`|Venda| |`vi`|Vietnamese| |`vo`|Volapük| |`wa`|Walloon| |`wo`|Wolof| |`xh`|Xhosa| |`yi`|Yiddish| |`yo`|Yoruba| |`za`|Zhuang, Chuang| |`zh`|Chinese| |`zu`|Zulu| **Parent topic:**[References](en_directory.md) --- # Currency codes {#en_currency_codes} A reference with the currency codes in the alpha-3 format of the ISO 4217 standard. In the Ecommpay payment platform, we use three-letter currency codes defined in the [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html) standard. These codes are used both in the HTTP-messages \(requests, responses, and callbacks\) and in user interfaces \(including Payment Page and Dashboard\). We use them in this documentation as well. The following table contains the codes of currencies used in payment processing. For each currency, the table lists the number of minor units, the name of the currency, and the region of its circulation. The codes are specified in the alpha-3 format of the ISO 4217:2015 standard. |Code|Minor units|Currency|Regions| |:--:|:---------:|--------|-------| |`AED`|2|UAE Dirham|United Arab Emirates \(the\)| |`AFN`|2|Afghani|Afghanistan| |`ALL`|2|Lek|Albania| |`AMD`|2|Armenian Dram|Armenia| |`ANG`|2|Netherlands Antillean Guilder|Curaçao, Sint Maarten \(Dutch Part\)| |`AOA`|2|Kwanza|Angola| |`ARS`|2|Argentine Peso|Argentina| |`AUD`|2|Australian Dollar|Australia, Christmas Island, Cocos \(Keeling\) Islands \(the\), Heard Island and McDonald Islands, Kiribati, Nauru, Norfolk Island, Tuvalu| |`AWG`|2|Aruban Florin|Aruba| |`AZN`|2|Azerbaijan Manat|Azerbaijan| |`BAM`|2|Convertible Mark|Bosnia and Herzegovina| |`BBD`|2|Barbados Dollar|Barbados| |`BDT`|2|Taka|Bangladesh| |`BGN`|2|Bulgarian Lev|Bulgaria| |`BHD`|3|Bahraini Dinar|Bahrain| |`BIF`|0|Burundi Franc|Burundi| |`BMD`|2|Bermudian Dollar|Bermuda| |`BND`|2|Brunei Dollar|Brunei Darussalam| |`BOB`|2|Boliviano|Bolivia \(Plurinational State of\)| |`BOV`|2|Mvdol|Bolivia \(Plurinational State of\)| |`BRL`|2|Brazilian Real|Brazil| |`BSD`|2|Bahamian Dollar|Bahamas \(the\)| |`BTN`|2|Ngultrum|Bhutan| |`BWP`|2|Pula|Botswana| |`BYN`|2|Belarusian Ruble|Belarus| |`BZD`|2|Belize Dollar|Belize| |`CAD`|2|Canadian Dollar|Canada| |`CDF`|2|Congolese Franc|Congo \(the Democratic Republic of the\)| |`CHE`|2|WIR Euro|Switzerland| |`CHF`|2|Swiss Franc|Liechtenstein, Switzerland| |`CHW`|2|WIR Franc|Switzerland| |`CLF`|4|Unidad de Fomento|Chile| |`CLP`|0|Chilean Peso|Chile| |`CNY`|2|Yuan Renminbi|China| |`COP`|2|Colombian Peso|Colombia| |`COU`|2|Unidad de Valor Real|Colombia| |`CRC`|2|Costa Rican Colon|Costa Rica| |`CUC`|2|Peso Convertible|Cuba| |`CUP`|2|Cuban Peso|Cuba| |`CVE`|2|Cabo Verde Escudo|Cabo Verde| |`CZK`|2|Czech Koruna|Czechia| |`DJF`|0|Djibouti Franc|Djibouti| |`DKK`|2|Danish Krone|Denmark, Faroe Islands \(the\), Greenland| |`DOP`|2|Dominican Peso|Dominican Republic \(the\)| |`DZD`|2|Algerian Dinar|Algeria| |`EGP`|2|Egyptian Pound|Egypt| |`ERN`|2|Nakfa|Eritrea| |`ETB`|2|Ethiopian Birr|Ethiopia| |`EUR`|2|Euro|Åland Islands, Andorra, French Guiana, French Southern Territories \(the\), Guadeloupe, Holy See \(the\), Martinique, Mayotte, Monaco, Montenegro, Réunion, Saint Barthélemy, Saint Martin \(French part\), Saint Pierre and Miquelon, San Marino, countries of the European Union except for Bulgaria, Czechia, Denmark, Hungary, Poland, Romania, Sweden| |`FJD`|2|Fiji Dollar|Fiji| |`FKP`|2|Falkland Islands Pound|Falkland Islands \(the\) \[Malvinas\]| |`GBP`|2|Pound Sterling|Guernsey, Isle of Man, Jersey, United Kingdom of Great Britain and Northern Ireland \(the\)| |`GEL`|2|Lari|Georgia| |`GHS`|2|Ghana Cedi|Ghana| |`GIP`|2|Gibraltar Pound|Gibraltar| |`GMD`|2|Dalasi|Gambia \(the\)| |`GNF`|0|Guinean Franc|Guinea| |`GTQ`|2|Quetzal|Guatemala| |`GYD`|2|Guyana Dollar|Guyana| |`HKD`|2|Hong Kong Dollar|Hong Kong| |`HNL`|2|Lempira|Honduras| |`HTG`|2|Gourde|Haiti| |`HUF`|2|Forint|Hungary| |`IDR`|2|Rupiah|Indonesia| |`ILS`|2|New Israeli Sheqel|Israel| |`INR`|2|Indian Rupee|Bhutan, India| |`IQD`|3|Iraqi Dinar|Iraq| |`IRR`|2|Iranian Rial|Iran \(Islamic Republic Of\)| |`ISK`|0|Iceland Krona|Iceland| |`JMD`|2|Jamaican Dollar|Jamaica| |`JOD`|3|Jordanian Dinar|Jordan| |`JPY`|0|Yen|Japan| |`KES`|2|Kenyan Shilling|Kenya| |`KGS`|2|Som|Kyrgyzstan| |`KHR`|2|Riel|Cambodia| |`KMF`|0|Comoro Franc|Comoros \(the\)| |`KPW`|2|North Korean Won|Korea \(the Democratic People's Republic of\)| |`KRW`|0|Won|Korea \(the Republic of\)| |`KWD`|3|Kuwaiti Dinar|Kuwait| |`KYD`|2|Cayman Islands Dollar|Cayman Islands \(the\)| |`KZT`|2|Tenge|Kazakhstan| |`LAK`|2|Lao Kip|Lao People's Democratic Republic \(the\)| |`LBP`|2|Lebanese Pound|Lebanon| |`LKR`|2|Sri Lanka Rupee|Sri Lanka| |`LRD`|2|Liberian Dollar|Liberia| |`LSL`|2|Loti|Lesotho| |`LYD`|3|Libyan Dinar|Libya| |`MAD`|2|Moroccan Dirham|Morocco, Western Sahara| |`MDL`|2|Moldovan Leu|Moldova \(the Republic of\)| |`MGA`|2|Malagasy Ariary|Madagascar| |`MKD`|2|Denar|North Macedonia| |`MMK`|2|Kyat|Myanmar| |`MNT`|2|Tugrik|Mongolia| |`MOP`|2|Pataca|Macao| |`MRU`|2|Ouguiya|Mauritania| |`MUR`|2|Mauritius rupee|Mauritius| |`MVR`|2|Rufiyaa|Maldives| |`MWK`|2|Malawi Kwacha|Malawi| |`MXN`|2|Mexican Peso|Mexico| |`MXV`|2|Mexican Unidad de Inversion \(UDI\)|Mexico| |`MYR`|2|Malaysian Ringgit|Malaysia| |`MZN`|2|Mozambique Metical|Mozambique| |`NAD`|2|Namibia Dollar|Namibia| |`NGN`|2|Naira|Nigeria| |`NIO`|2|Cordoba Oro|Nicaragua| |`NOK`|2|Norwegian Krone|Bouvet Island, Norway, Svalbard and Jan Mayen| |`NPR`|2|Nepalese Rupee|Nepal| |`NZD`|2|New Zealand Dollar|Cook Islands \(the\), New Zealand, Niue, Pitcairn, Tokelau| |`OMR`|3|Rial Omani|Oman| |`PAB`|2|Balboa|Panama| |`PEN`|2|Sol|Peru| |`PGK`|2|Kina|Papua New Guinea| |`PHP`|2|Philippine Peso|Philippines \(the\)| |`PKR`|2|Pakistani rupee|Pakistan| |`PLN`|2|Zloty|Poland| |`PYG`|0|Guarani|Paraguay| |`QAR`|2|Qatari Rial|Qatar| |`RON`|2|Romanian Leu|Romania| |`RSD`|2|Serbian Dinar|Serbia| |`RUB`|2|Russian Ruble|Russian Federation \(the\)| |`RWF`|0|Rwandan Franc|Rwanda| |`SAR`|2|Saudi Riyal|Saudi Arabia| |`SBD`|2|Solomon Islands Dollar|Solomon Islands| |`SCR`|2|Seychelles Rupee|Seychelles| |`SDG`|2|Sudanese Pound|Sudan \(the\)| |`SEK`|2|Swedish Krona|Sweden| |`SGD`|2|Singapore Dollar|Singapore| |`SHP`|2|Saint Helena Pound|Saint Helena, Ascension and Tristan Da Cunha| |`SLL`|2|Leone|Sierra Leone| |`SOS`|2|Somali Shilling|Somalia| |`SRD`|2|Surinam Dollar|Suriname| |`SSP`|2|South Sudanese Pound|South Sudan| |`STN`|2|Dobra|Sao Tome and Principe| |`SVC`|2|El Salvador Colon|El Salvador| |`SYP`|2|Syrian Pound|Syrian Arab Republic| |`SZL`|2|Lilangeni|Eswatini| |`THB`|2|Baht|Thailand| |`TJS`|2|Somoni|Tajikistan| |`TMT`|2|Turkmenistan New Manat|Turkmenistan| |`TND`|3|Tunisian Dinar|Tunisia| |`TOP`|2|Paʻanga|Tonga| |`TRY`|2|Turkish Lira|Türki̇ye| |`TTD`|2|Trinidad and Tobago Dollar|Trinidad and Tobago| |`TWD`|2|New Taiwan Dollar|Taiwan \(Province of China\)| |`TZS`|2|Tanzanian Shilling|Tanzania, the United Republic of| |`UAH`|2|Hryvnia|Ukraine| |`UGX`|0|Ugandan Shilling|Uganda| |`USD`|2|US Dollar|American Samoa, Bonaire, Sint Eustatius and Saba, British Indian Ocean Territory \(the\), Ecuador, El Salvador, Guam, Haiti, Marshall Islands \(the\), Micronesia \(Federated States of\), Northern Mariana Islands \(the\), Palau, Panama, Puerto Rico, Timor-Leste, Turks and Caicos Islands \(the\), United States Minor Outlying Islands \(the\), United States of America \(the\), Virgin Islands \(British\), Virgin Islands \(U.S.\)| |`UYI`|0|Uruguay Peso en Unidades|Uruguay| |`UYU`|2|Peso Uruguayo|Uruguay| |`UYW`|4|Unidad Previsional|Uruguay| |`UZS`|2|Uzbekistan Sum|Uzbekistan| |`VED`|2|Bolívar Soberano|Venezuela \(Bolivarian Republic of\)| |`VES`|2|Bolívar Soberano|Venezuela \(Bolivarian Republic of\)| |`VND`|0|Dong|Viet Nam| |`VUV`|0|Vatu|Vanuatu| |`WST`|2|Tala|Samoa| |`XAF`|0|CFA Franc BEAC|Cameroon, Central African Republic \(the\), Chad, Congo \(the\), Equatorial Guinea, Gabon| |`XCD`|2|East Caribbean Dollar|Anguilla, Antigua and Barbuda, Dominica, Grenada, Montserrat, Saint Kitts and Nevis, Saint Lucia, Saint Vincent and the Grenadines| |`XOF`|0|CFA Franc BCEAO|Benin, Burkina Faso, Côte d'Ivoire, Guinea-Bissau, Mali, Niger \(the\), Senegal, Togo| |`XPF`|0|CFP Franc|French Polynesia, New Caledonia, Wallis and Futuna| |`YER`|2|Yemeni Rial|Yemen| |`ZAR`|2|Rand|Lesotho, Namibia, South Africa| |`ZMW`|2|Zambian Kwacha|Zambia| |`ZWL`|2|Zimbabwe Dollar|Zimbabwe| **Parent topic:**[References](en_directory.md) --- # Payment method codes {#en_pm_codes} A reference with the internal codes of supported payment methods relevant to working with different interfaces of the platform. When working with various interfaces of the Ecommpay payment platform, you can use service codes of payment methods. For example, you have to use a code in a request for opening Payment Page to preselect a payment method \(the code is specified as a value of the `force_payment_method` parameter\) or to filter out a certain payment method \(the code is specified as a value of the `hide` parameter\).When working with the Gate API, you have to use payment method codes to check payment method availability, while in Dashboard these codes are needed to issue payouts and refunds. **Note:** Preselecting payment method groups with service codes is also supported when using Payment Page. To preselect a group, specify the relevant code as a value of the `force_payment_group` parameter in the request. These codes include the `openbanking` code for selecting the Open Banking methods group. Keep in mind that depending on the interface you may have to use different codes for the same payment method. The following table contains the codes for Payment Page, Gate, and Dashboard interfaces.Some of the codes listed in the **Gate, Dashboard** column can only be used for working with the Gate API. Such codes are marked with Gate only. If you have any questions about working with individual codes, contact the Ecommpay technical support. |Payment method|Payment Page|Gate,Dashboard| |--------------|------------|--------------| |[Standard card payments](en_pm_card_payments.md)|`card`|- `card` \(when using card numbers\) - `card-token` \(when using card tokens\) | |[Alipay](pm_alipay.md#)|`alipay`|`wallet/alipay`| |[Apple Pay](pm_applepay.md#)|- `card` \(combined with direct use of cards\) - `apple_pay_core` \(only by using the Apple Pay service\) |`etoken`| |[AstroPay](pm_astropay.md#)|`astropay`|`wallet/astropay`| |[Bancontact](pm_bancontact.md#)|`bancontact`|`bancontact`| |[Bancomat Pay](pm_bancomatpay.md#)|`bancomatpay`|`wallet/bancomatpay`| |[Banks of Hong Kong](pm_hk_banks.md#)|–|`banks/hk`| |[Banks of the Philippines](pm_philippines.md#)|`online-philippines-banks`|`banks/philippines`| |[Blik](pm_blik.md#)|`blik`|`blik`| |[Boost Wallet](pm_boost.md#)|`boost`|`wallet/boost` Gate only| |[Brazil Online Banking](pm_brazil_ob.md#)|`online-brazil-banks`|`banks/brazil`| |[Buy Now Pay Later](pm_bnpl.md#)|`bnpl-humm`|`bnpl/humm`Gate only| |[Chile Online Banking](pm_chile_ob.md#)|`online-chile-banks`|`banks/chile`| |[China UnionPay](pm_unionpay.md#)|`cup-union`|`unionpay`| |[Click to Pay](pm_clicktopay.md#)|`etoken-click2pay`|`etoken-click2pay`| |[Coins.ph](pm_coinsph.md#)|`coinsph-wallet`|`wallet/coinsph`| |[Direct Debit BACS](pm_dd_bacs.md#)|`directdebit-bacs`|`bacs` Gate only| |[Direct Debit SEPA](pm_dd_sepa.md#)|`directdebit-sepa`|`sepa` Gate only| |[DOKU Wallet](pm_doku.md#)|`doku`|`wallet/doku`| |[Ecuador Online Banking](pm_ecuador_ob.md#)|`online-ecuador-banks`|`banks/ecuador`| |[EPS](pm_eps.md#)|`eps`|`bank-transfer/eps` Gate only| |[GCash](pm_gcash.md#)|`gcash-wallet`|`wallet/gcash`| |[Google Pay](pm_googlepay.md#)|- `card` \(combined with direct use of cards\) - `google_pay_host` \(only by using the Google Pay service\) |- `card` \(combined with direct use of cards\) - `google-pay` \(only by using the Google Pay service\) | |[GrabPay](pm_grabpay.md#)|`grabpay-wallet`|`wallet/grabpay`| |[Hong Kong FPS QR](pm_hk_qr.md#)|`hk-qr`|`banks/hk-qr` Gate only| |[Indonesian Online Banking](pm_indonesia.md#)|`online-indonesian-banks`|`banks/indonesia`| |[Indonesian Virtual Accounts](pm_indonesia_va.md#)|`indonesia-va`|`banks/indonesia`Gate only| |[iDEAL \| Wero](pm_ideal.md#)|`ideal`|`online-banking/ideal`| |[Local payouts to bank accounts in the UK](pm_bankpayout_uk.md#)|–|`bank-transfer/uk`| |[Malaysian Online Banking](pm_malaysia.md#)|`online-malaysian-banks`|`banks/malaysia`| |[Maya](pm_maya.md#)|`paymaya-wallet`|`wallet/paymaya`| |[MBWay](pm_mbway.md#)|`mbway`|`wallet/mbway`| |[Mexico Online Banking](pm_mexico_ob.md#)|`online-mexico-banks`|`banks/mexico`| |[MoMo Wallet](pm_momoqr.md#)|`momopay`|`momopay` Gate only| |[Multibanco](pm_multibanco.md#)|`multibanco`|`bank-transfer/multibanco`Gate only| |[MyBank](pm_mybank.md#)|`mybank`|`banks/mybank`| |[Neteller](pm_neteller.md#)|`neteller-wallet`|`wallet/neteller`| |[Open Banking in Austria](pm_austria.md#)|`online-austrian-banks`|`banks/austria` Gate only| |[Open Banking in Belgium](pm_belgium.md#)|`online-belgian-banks`|`banks/belgium` Gate only| |[Open Banking in Denmark](pm_denmark.md#)|`online-danish-banks`|`banks/denmark` Gate only| |[Open Banking in Estonia](pm_estonia.md#)|`online-estonian-banks`|`banks/estonia` Gate only| |[Open Banking in Finland](pm_finland.md#)|`online-finnish-banks`|`banks/finland` Gate only| |[Open Banking in France](pm_france.md#)|`online-french-banks`|`banks/france` Gate only| |[Open Banking in Germany](pm_germany.md#)|`online-german-banks`|`banks/germany` Gate only| |[Open Banking in Hungary](pm_hungary.md#)|`online-hungarian-banks`|`banks/hungary` Gate only| |[Open Banking in Ireland](pm_ireland.md#)|`online-irish-banks`|`banks/ireland` Gate only| |[Open Banking in Italy](pm_italy.md#)|`online-italian-banks`|`banks/italy` Gate only| |[Open Banking in Latvia](pm_latvia.md#)|`online-latvian-banks`|`banks/latvia` Gate only| |[Open Banking in Lithuania](pm_lithuania.md#)|`online-lithuanian-banks`|`banks/lithuania` Gate only| |[Open Banking in Luxembourg](pm_luxembourg.md#)|`online-luxembourg-banks`|`banks/luxembourg` Gate only| |[Open Banking in the Netherlands](pm_netherlands.md#)|`online-netherlands-banks`|`banks/netherlands` Gate only| |[Open Banking in Norway](pm_norway.md#)|`online-norwegian-banks`|`banks/norway` Gate only| |[Open Banking in Poland](pm_poland.md#)|`online-polish-banks`|`banks/poland` Gate only| |[Open Banking in Portugal](pm_portugal.md#)|`online-portuguese-banks`|`banks/portugal` Gate only| |[Open Banking in Romania](pm_romania.md#)|`online-romanian-banks`|`banks/romania` Gate only| |[Open Banking in Spain](pm_spain.md#)|`online-spanish-banks`|`banks/spain` Gate only| |[Open Banking in Sweden](pm_sweden.md#)|`online-swedish-banks`|`banks/sweden` Gate only| |[Open Banking in the UK](pm_uk.md#)|`uk`|`banks/uk` Gate only| |[OVO Wallet](pm_ovo.md#)|`ovo`|`wallet/ovo`| |[Payouts to bank accounts in SEPA](pm_bankpayout_sepa.md#)|–|`bank-transfer/world`| |[Paypal](pm_paypal.md#)|`paypal-wallet`|`wallet/paypal`| |[PayPal Pay Later](pm_paypal_pay_later.md#)|`paypal-wallet`|`wallet/paypal`| |[Peru Online Banking](pm_peru_ob.md#)|`online-peru-banks`|`banks/peru`| |[Philippines Over the Counter & ATM](pm_philippines_atm.md#)|`philippines-atm`|`atm/philippines`Gate only| |[PIX](pm_pix.md#)|`pix`|`pix`| |[Promptpay](pm_promptpay.md#)|`promptpay`|`banks/promptpay`Gate only| |[Przelewy24](pm_przelewy.md#)|`przelewy24`|`online-banking/przelewy24`| |[QRIS](pm_qris.md#)|`indonesia-qr`|`banks/indonesia-qr` Gate only| |[QR Ph](pm_qrph.md#)|`ph-qr`|`qr/ph-qr` Gate only| |[Satispay](pm_satispay.md#)|`satispay`|`wallet/satispay`| |[Shopee](pm_shopee.md#)|`shopee`|`wallet/shopee` Gate only| |[Skrill Wallet](pm_skrill.md#)|`skrill`|`skrill`| |[Swish](pm_swish.md#)|`swish`|`banks/swish`| |[Thai Online Banking](pm_thailand.md#)|`online-thailand-banks`|`banks/thailand`| |[Touch&Go](pm_touchngo.md#)|`touchngo_wallet`|`wallet/touchngo`| |[TrueMoney](pm_truemoney.md#)|`true-money`|`wallet/true-money` Gate only| |[TWINT](pm_twint.md#)|`twint`|`wallet/twint`| |[Vietnamese Online Banking](pm_vietnam.md#)|`online-vietnam-banks`|`banks/vietnam`| |[WeChat](pm_wechat.md#)|`wechat`|`wallet/wechat`| **Parent topic:**[References](en_directory.md) --- # Payment card codes {#en_card_codes} A reference with the internal codes indicating the payment card brands that can be used for working with the platform. When you work with different interfaces of the Ecommpay payment platform, you may need to use specialised codes to indicate the card [brand](en_glossary.md#) while processing card payments. In particular, such codes can be passed in requests for opening Payment Page with the preselected card brand\(specified in the `force_payment_method_subtype` parameter\) and callbacks. In addition, the information about card brands is shown in Dashboard. These codes are listed in the following table. |Code|Brand| |----|-----| |`amex`|American Express| |`maestro`|Maestro| |`mastercard`|Mastercard| |`visa`|Visa| **Parent topic:**[References](en_directory.md) --- # Country codes {#en_country_codes} A reference with the country codes in the alpha-2 format of the ISO 3166-1 standard. When working with various interfaces of the Ecommpay payment platform, you may need to use short letter codes for country names, namely the two-letter country codes defined in the [ISO 3166-1](https://www.iso.org/iso-3166-country-codes.html) standard. For example, you have to specify a country code together with other customer information in requests to open Payment Pageand in requests to perform payments via Gate. You can also come across these codes within this documentation. The following table contains the country codes in the alpha-2 format of the ISO 3166-1:2020 standard. |Code|Country| |:--:|-------| |`AD`|Andorra| |`AE`|United Arab Emirates \(the\)| |`AF`|Afghanistan| |`AG`|Antigua and Barbuda| |`AI`|Anguilla| |`AL`|Albania| |`AM`|Armenia| |`AO`|Angola| |`AQ`|Antarctica| |`AR`|Argentina| |`AS`|American Samoa| |`AT`|Austria| |`AU`|Australia| |`AW`|Aruba| |`AX`|Åland Islands| |`AZ`|Azerbaijan| |`BA`|Bosnia and Herzegovina| |`BB`|Barbados| |`BD`|Bangladesh| |`BE`|Belgium| |`BF`|Burkina Faso| |`BG`|Bulgaria| |`BH`|Bahrain| |`BI`|Burundi| |`BJ`|Benin| |`BL`|Saint Barthélemy| |`BM`|Bermuda| |`BN`|Brunei Darussalam| |`BO`|Bolivia \(Plurinational State of\)| |`BQ`|Bonaire, Sint Eustatius and Saba| |`BR`|Brazil| |`BS`|Bahamas \(the\)| |`BT`|Bhutan| |`BV`|Bouvet Island| |`BW`|Botswana| |`BY`|Belarus| |`BZ`|Belize| |`CA`|Canada| |`CC`|Cocos \(Keeling\) Islands \(the\)| |`CD`|Congo \(the Democratic Republic of the\)| |`CF`|Central African Republic \(the\)| |`CG`|Congo \(the\)| |`CH`|Switzerland| |`CI`|Côte d'Ivoire| |`CK`|Cook Islands \(the\)| |`CL`|Chile| |`CM`|Cameroon| |`CN`|China| |`CO`|Colombia| |`CR`|Costa Rica| |`CU`|Cuba| |`CV`|Cabo Verde| |`CW`|Curaçao| |`CX`|Christmas Island| |`CY`|Cyprus| |`CZ`|Czechia| |`DE`|Germany| |`DJ`|Djibouti| |`DK`|Denmark| |`DM`|Dominica| |`DO`|Dominican Republic \(the\)| |`DZ`|Algeria| |`EC`|Ecuador| |`EE`|Estonia| |`EG`|Egypt| |`EH`|Western Sahara| |`ER`|Eritrea| |`ES`|Spain| |`ET`|Ethiopia| |`FI`|Finland| |`FJ`|Fiji| |`FK`|Falkland Islands \(the\) \[Malvinas\]| |`FM`|Micronesia \(Federated States of\)| |`FO`|Faroe Islands \(the\)| |`FR`|France| |`GA`|Gabon| |`GB`|United Kingdom of Great Britain and Northern Ireland \(the\)| |`GD`|Grenada| |`GE`|Georgia| |`GF`|French Guiana| |`GG`|Guernsey| |`GH`|Ghana| |`GI`|Gibraltar| |`GL`|Greenland| |`GM`|Gambia \(the\)| |`GN`|Guinea| |`GP`|Guadeloupe| |`GQ`|Equatorial Guinea| |`GR`|Greece| |`GS`|South Georgia and the South Sandwich Islands| |`GT`|Guatemala| |`GU`|Guam| |`GW`|Guinea-Bissau| |`GY`|Guyana| |`HK`|Hong Kong| |`HM`|Heard Island and McDonald Islands| |`HN`|Honduras| |`HR`|Croatia| |`HT`|Haiti| |`HU`|Hungary| |`ID`|Indonesia| |`IE`|Ireland| |`IL`|Israel| |`IM`|Isle of Man| |`IN`|India| |`IO`|British Indian Ocean Territory \(the\)| |`IQ`|Iraq| |`IR`|Iran \(Islamic Republic of\)| |`IS`|Iceland| |`IT`|Italy| |`JE`|Jersey| |`JM`|Jamaica| |`JO`|Jordan| |`JP`|Japan| |`KE`|Kenya| |`KG`|Kyrgyzstan| |`KH`|Cambodia| |`KI`|Kiribati| |`KM`|Comoros \(the\)| |`KN`|Saint Kitts and Nevis| |`KP`|Korea \(the Democratic People's Republic of\)| |`KR`|Korea \(the Republic of\)| |`KW`|Kuwait| |`KY`|Cayman Islands \(the\)| |`KZ`|Kazakhstan| |`LA`|Lao People's Democratic Republic \(the\)| |`LB`|Lebanon| |`LC`|Saint Lucia| |`LI`|Liechtenstein| |`LK`|Sri Lanka| |`LR`|Liberia| |`LS`|Lesotho| |`LT`|Lithuania| |`LU`|Luxembourg| |`LV`|Latvia| |`LY`|Libya| |`MA`|Morocco| |`MC`|Monaco| |`MD`|Moldova \(the Republic of\)| |`ME`|Montenegro| |`MF`|Saint Martin \(French part\)| |`MG`|Madagascar| |`MH`|Marshall Islands \(the\)| |`MK`|North Macedonia| |`ML`|Mali| |`MM`|Myanmar| |`MN`|Mongolia| |`MO`|Macao| |`MP`|Northern Mariana Islands \(the\)| |`MQ`|Martinique| |`MR`|Mauritania| |`MS`|Montserrat| |`MT`|Malta| |`MU`|Mauritius| |`MV`|Maldives| |`MW`|Malawi| |`MX`|Mexico| |`MY`|Malaysia| |`MZ`|Mozambique| |`NA`|Namibia| |`NC`|New Caledonia| |`NE`|Niger \(the\)| |`NF`|Norfolk Island| |`NG`|Nigeria| |`NI`|Nicaragua| |`NL`|Netherlands \(Kingdom of the\)| |`NO`|Norway| |`NP`|Nepal| |`NR`|Nauru| |`NU`|Niue| |`NZ`|New Zealand| |`OM`|Oman| |`PA`|Panama| |`PE`|Peru| |`PF`|French Polynesia| |`PG`|Papua New Guinea| |`PH`|Philippines \(the\)| |`PK`|Pakistan| |`PL`|Poland| |`PM`|Saint Pierre and Miquelon| |`PN`|Pitcairn| |`PR`|Puerto Rico| |`PS`|Palestine, State of| |`PT`|Portugal| |`PW`|Palau| |`PY`|Paraguay| |`QA`|Qatar| |`RE`|Réunion| |`RO`|Romania| |`RS`|Serbia| |`RU`|Russian Federation \(the\)| |`RW`|Rwanda| |`SA`|Saudi Arabia| |`SB`|Solomon Islands| |`SC`|Seychelles| |`SD`|Sudan \(the\)| |`SE`|Sweden| |`SG`|Singapore| |`SH`|Saint Helena, Ascension and Tristan da Cunha| |`SI`|Slovenia| |`SJ`|Svalbard and Jan Mayen| |`SK`|Slovakia| |`SL`|Sierra Leone| |`SM`|San Marino| |`SN`|Senegal| |`SO`|Somalia| |`SR`|Suriname| |`SS`|South Sudan| |`ST`|Sao Tome and Principe| |`SV`|El Salvador| |`SX`|Sint Maarten \(Dutch part\)| |`SY`|Syrian Arab Republic \(the\)| |`SZ`|Eswatini| |`TC`|Turks and Caicos Islands \(the\)| |`TD`|Chad| |`TF`|French Southern Territories \(the\)| |`TG`|Togo| |`TH`|Thailand| |`TJ`|Tajikistan| |`TK`|Tokelau| |`TL`|Timor-Leste| |`TM`|Turkmenistan| |`TN`|Tunisia| |`TO`|Tonga| |`TR`|Türkiye| |`TT`|Trinidad and Tobago| |`TV`|Tuvalu| |`TW`|Taiwan \(Province of China\)| |`TZ`|Tanzania, the United Republic of| |`UA`|Ukraine| |`UG`|Uganda| |`UM`|United States Minor Outlying Islands \(the\)| |`US`|United States of America \(the\)| |`UY`|Uruguay| |`UZ`|Uzbekistan| |`VA`|Holy See \(the\)| |`VC`|Saint Vincent and the Grenadines| |`VE`|Venezuela \(Bolivarian Republic of\)| |`VG`|Virgin Islands \(British\)| |`VI`|Virgin Islands \(U.S.\)| |`VN`|Viet Nam| |`VU`|Vanuatu| |`WF`|Wallis and Futuna| |`WS`|Samoa| |`YE`|Yemen| |`YT`|Mayotte| |`ZA`|South Africa| |`ZM`|Zambia| |`ZW`|Zimbabwe| **Parent topic:**[References](en_directory.md) --- # Region codes for card payments {#en_region_codes} A reference with the region codes used in processing Mastercard and Visa payments via Ecommpay. When processing card payments according to the rules and requirements of global card networks, you should track the information about the customer's and the merchant's countries. It strengthens compliance with the existing regulations, ensures proper application of relevant fees, and facilitates payment traffic analysis \(including fraud detection\). The *customer country* is the country where the customer's card account is registered. The *merchant country* is the country where the headquarters or the store of the merchant is registered. To identify different combinations of these two parameters, the card networks use special codes. When you work with the Ecommpay payment platform, these codes are specified in HTTP responses and callbacks. The following tables contain region codes used in processing payments made with Mastercard and Visa. |Code|Description| |----|-----------| |`domestic`|The merchant country and the customer country match.| |`intereuropean`|Both the merchant country and the customer country are part of the European region, but only one of them is part of the Single Euro Payments Area\(SEPA\).| |`interregional`|The merchant country is part of the European region. The customer country is not.| |`non-sepa`|Both the merchant country and the customer country are part of the European region and are not part of the Single Euro Payments Area\(SEPA\).| |`sepa (eea)`|Both the merchant country and the customer country are part of the European region, the Single Euro Payments Area\(SEPA\), and the European Economic Area\(EEA\).| |`sepa (non-eea)`|Both the merchant country and the customer country are part of the European region, the Single Euro Payments Area\(SEPA\), but either one of them or both are not part of the European Economic Area\(EEA\).| |Code|Description| |----|-----------| |`domestic`|In case of purchases: the merchant country and the customer country match. In case of payouts: the merchant country and the customer country match, while one of the following conditions is true: - The countries of the merchant, customer, issuer, and acquirer are all part of the European Economic Area\(EEA\), while the countries of the acquirer and the issuer can differ from the country of the merchant and the customer. - The countries of the merchant, customer, issuer, and acquirer all match, while the payment country can be outside of the European Economic Area \(EEA\). | |`international`|The merchant country and the customer country belong to different Visa regions.| |`eea`|Both the merchant country and the customer country are part of the European Economic Area\(EEA\).| |`non-eea isr, tur`|One of the countries is Israel or Turkey, while the other is part of the European region.| |`non-eea che`|One of the countries is Switzerland, while the other is part of the European region and is not Israel or Turkey.| |`non-eea other`|One of the countries is Andorra, Monaco, San Marino, or the Vatican City State, while the other is part of the European region and is not Switzerland, Israel, or Turkey.| **Parent topic:**[References](en_directory.md) --- # Test cards {#en_test_cards} A reference with card numbers that can be used for testing different card payment scenarios. ## General information {#section_evj_j3p_hhb .section} To check the validity of the technical integration and different user scenarios for card payments, you are recommended to try processing test payments in the test projects using test cards listed in this reference. With test cards, the processing scenario is selected based on the card number. Other parameters, such as payment amount, cardholder name, or verification code, can take arbitrary values \(unless otherwise noted\), but they must be specified in the correct format. For example, the card expiry date cannot predate the payment date. **Note:** In addition to testing card payments, the platform supports testing alternative payments \([details](en_pm_testing.md)\) If you have questions about testing payment processing, contact the Ecommpay technical support. ## Testing purchases {#section_iky_s43_qrb .section} You can test processing purchases with different user scenarios by using test card numbers in the following tables. |Card|Card network|Status|Notes| |----|------------|------|-----| |`4000 0000 0000 0077`|Visa|`success`|–| |`4111 1111 1111 1111`|Visa|`decline`|–| |`4000 0000 0000 0119`|Visa|`success`|Payment to register a COF purchase| |`4000 0000 0000 0119`|Visa|`decline`|Debit operation performed as part of the registered COF purchase is declined due to invalid card data, error code `10102`| |`4000 0000 0000 0135`|Visa|`success`|Payment to register a COF purchase| |`4000 0000 0000 0135`|Visa|`decline`|Debit operation performed as part of the registered COF purchase is declined due to insufficient funds on the card, error code `10105`| |`4539 1214 1116 8251`|Visa|`decline`|Payment is declined due to an issuer timeout| |`5126 1600 0035 6675`|Mastercard|`success`|Payment with partial authorisation is approved \(if this capability is enabled and the purchase amount in the request is greater than 120 EUR, [details](en_gate_partial_approval.md)\)| |`4010 5716 7622 3548`|Visa|`success`|Payment with partial authorisation is approved \(if this capability is enabled and the purchase amount in the request is greater than 120 EUR, [details](en_gate_partial_approval.md)\)| |Card|Card network|Status|Notes| |----|------------|------|-----| |`4314 2200 0000 0056`|Visa|`success`|Challenge flow when the ACS page is displayed for entering the code| |`4477 0000 0000 0006`|Visa|`success`|Frictionless flow| |`5413 3300 0000 0019`|Mastercard|`success`|Challenge flow when the ACS page is displayed for entering the code| |`5544 3300 0000 0045`|Mastercard|`decline`|Challenge flow when the ACS page is displayed for entering the code| |`5252 0000 0000 0004`|Mastercard|`success`|Frictionless flow| ## Testing payouts {#section_sht_v43_qrb .section} You can test issuing payouts by using test card numbers in the following table. |Card|Card network|Status| |----|------------|------| |`4242 4242 4242 4242`|Visa|`success`| |`4314 2200 0000 0072`|Visa|`decline`| |`5413 3300 0000 0019`|Mastercard|`success`| |`5413 3300 0000 0035`|Mastercard|`decline`| **Parent topic:**[References](en_directory.md) --- # Electronic Commerce Indicators {#en_ECI_codes} A reference with the Electronic Commerce Indicators used by different card networks to communicate the results of the 3‑D Secure authentication of customers. Electronic Commerce Indicator \(ECI\) conveys the result of the customer \(cardholder\) 3‑D Secure authentication. This indicator is used for registering whether the authentication was initiated, the authentication outcome, and which party—either the issuer or the merchant—is responsible for approving payment processing and will take potential financial responsibility if a chargeback occurs. An ECI is defined by the issuer on the side of the \(Access Control Server, ACS\) or the card network based on the result of the authentication attempt; however in some cases, there can be no ECI assigned—for example, if the customer has specified a wrong one-time code \(within the challenge flow\) or the issuer has identified a high risk of fraud when checking the customer information \(within the frictionless flow\). Depending on the authentication result, the operation processing can be either continued or declined, which is also reflected by the ECI. When the operation is declined following the results of the authentication, payment processing can continue, in particular if the capability of [payment retries](en_PP_Try_Again.md)or [cascade payment processing](en_pp_cascading.md#) is set up. ECIs are applied regardless of the protocol version and the flow of the 3‑D Secure authentication; along with that, different card networks use different coding variants. In the Ecommpay payment platform, ECIs are generally represented as two-digit codes with a leading zero, but in certain cases other formats can be applied. The ECI values are sent to the merchant web service in final callbacks with the information about payment processing in the `eci` parameter of the `operation` object. The following table provides the information about the ECIs of different card networks for basic payment scenarios. For the information about other situations, contact the Ecommpay technical support specialists. |Situation|Responsible party|ECI| |---------|-----------------|---| |The authentication is completed with the customer identity verification.The operation processing can be continued. |Issuer|- American Express—`05` - Mastercard—`02` \(in general cases\), `07` \(during the registration of the COF purchases;[details](en_gate_payment_recurring_registration.md)\) - Visa—`05` | |The authentication is initiated on the part of the merchant and acquirer but cannot be performed by the issuer.The operation processing can be either continued or declined depending on the issuer's decision. |Issuer|- American Express—`06` - Mastercard—`01` - Visa—`06` | |One of the following cases is identified:- The authentication is not initiated on the part of the merchant. - The authentication is initiated on the part of the merchant and acquirer, but while performing it, the issuer could not verify the customer identity. According to the merchant's decision, the operation processing can be continued. |Merchant|- American Express—`07` - Mastercard—`00` - Visa—`07` | **Parent topic:**[References](en_directory.md) ---