Payments

The Payment Page payment form opens by default after the customer selects a payment method on the payment method selection page.

The Payment Page payment form opens by default after the customer selects a payment method on the payment method selection page. 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.

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.

Customer IP address and identifier are required for processing financial operations in the Openpayze platform and needed for analysing the operations for fraud. That is why, if this data is omitted or incorrect, operations can be declined.Customer IP address and identifier are among the required parameters for performing financial operations within the Openpayze 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.

When specifying the first and last names of a customer and/or a cardholder, it is important to meet a number of conditions for forming requests, since these parameters are checked not only for correctness of the data format but also according to different rules including fraud prevention rules.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, 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 Latin letters without diacritics, Cyrillic letters, periods in abbreviations, an apostrophe, hyphens in compound names:
  • Latin letters without diacritics;
  • Cyrillic letters;
  • periods in abbreviations (for example, Mr. or Jr.);
  • an apostrophe (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 there are no hyphens for abbreviations and contractions because hyphens are considered as word separators (or example, specifying M-r Holder is incorrect). For example, specifying M-r Holder is incorrect since this construction contains three words with two words consisting of a single letter.

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.

The meaning of the term ‘refund’ in the payment platform. In the Openpayze 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 the actual payment amount amount 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.
  

• 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.
  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 and, if relevant, Data API.

For more detailed information, refer to the article Purchase refunds.

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 the Purchase refunds article.

When working via Dashboard, use the tools for issuing single and mass refunds described in the corresponding article.

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.