Getting started

Getting started

Quick start

ePayments Merchant Services Limited (henceforth - EMS) is a service allowing online stores and online services to accept payments made via bankcards and payment systems.

Before you can begin to accept payments, please, select your preferred method of integration with EMS:

Integration via API

If you require a full API integration with the EMS service, please complete the following steps:

  1. Fill out an application.
    Send an integration request and provide data on your online store (see the Getting Access). As a result, you will receive individual settings and data to access the EMS API.

  2. Select a payment scenario.
    EMS provides the following methods of creating invoices and accepting payments:

    • Redirect - the buyer initiates payment on merchant’s site, but is redirected to the EMS payment page for payment;
    • Iframe - the buyer initiates and pays through merchant site;
    • Invoicing - payment link is generated by the merchant is sent to the buyer receives in an email. The link itself leads to the EMS payment page, where buyer completes the payment.
    • Direct – the buyer initiates payment on your website and enters payment details in your payment form.

  3. Create a payment.
    To transfer the information the payment information use one of the following methods GET /paymentpage (for the Redirect, Iframe orInvoicing) or the POST /payment method (for the Direct payments).

  4. Get results.
    After the invoice is paid, you will be sent a callback - notification regarding payment status.

EMS test store
Before sending an application for store registration, you can familiarize yourself with the EMS service capabilities using our test store and test payment details. The only difference is that you will not be able to receive notifications about the status of the payment, since callback will be sent to the URL of the test store.

Integration without API

You can create and send an invoice to the buyer without API integration. To do this, please complete the following steps:

  1. Fill out an application.
    Send a request to connect to EMS to get individual store settings (see the Getting Access).

  2. Open web form.
    Go to the https://ms.epayments.com/create-invoice and fill out the proposed fields, using the store settings provided by the EMS (see the Web-form usage).

  3. Send an invoice to the buyer.
    Copy the generated link and send it to the buyer. When clicking on the link, the buyer will be see the EMS payment page, using which they will be able to pay invoice.

  4. Get results.
    After the invoice is paid, you will be sent a email - notification regarding payment status.

Getting access

To register an online store in EMS the merchant must contact their account manager or support service team (through the ticket system). The following attributes must be included in the request:

AttributesMandatoryDescription
ShopSupportYesContact details of the online store’s support team. It is possible to enter the phone number or the email address of the support team as contact details
DefaultCurrency
Id
YesCurrency for crediting payments to the online store’s account. This currency is required if the payment currency does not correspond to one of the currencies of the store in EMS (in this case conversion will occur at EMS)
WebsiteUrlYesOnline store’s website. Only one site can be entered for an online store
IpAddressTestYesIP addresses from which access to the test environment must be provided
IpAddressProdYesIP addresses from which access to the live environment must be provided
MerchantEmailYesMerchant’s email to which invoice payment results will be sent. This consists of a copy of the notification sent to the buyer after carrying out the payment
HoldExpDaysYesThe period of time during which funds will remain frozen/blocked on the buyer’s and available for the debit. The value can vary from 1 to 28 days
CallbackUrlYesPage to which information about the result of the payment will be transmitted
DefaultUrlNoPage to which the buyer is returned after clicking on the “Back to store” button prior to receiving the result (i.e. the buyer declined to pay upon his/her own initiative)
FailUrlNoPage to which the buyer will be redirected if an error occurs when carrying out the payment
SuccessUrlNoPage to which the buyer will be redirected if the payment is successfully carried out
OperationLife
Time
NoInvoice validity period prior to its payment. Displayed in minutes. Values from 1 to 4320 accepted
TimeToRejectNoThe timeframe during which a buyer can pay the invoice. The countdown starts the moment the buyer opens the payment page. Only integer values, in minutes can be used. The maximum value is 240


Receiving notifications
The merchant can choose one of the following methods to receive notifications about completed payments:
  • via callback only (enabled by default);
  • via email only (disabled by default);
  • via callback and email (disabled by default).

The merchant selects the method of receiving notifications during their registration. If the merchant does not select any particular method for receiving notifications, then, by default, all notifications will be sent in a callback format or as an email if the shopEmail parameter was sent along in the GET /paymentpage.


“Mandatory” attribute - means that it can be transmitted only during online store registration. Subsequent changes to the submitted data will only possible via the EMS support team.

“Non-mandatory” attribute - means that it can be transmitted both during registration and when sending a request to create a payment page GET /paymentpage. Such a setting will allow the merchant to manage these attributes’ values themselves:

  • If the merchant has not transmitted a non-mandatory attribute during registration, he/she must provide it whenever calling GET /paymentpage.
  • If the merchant transmitted a non-mandatory attribute during registration, he/she does not need to provide it when requesting GET /paymentpage. If the merchant sends this attribute to GET /paymentpage. with a new value, then this value will be sent in the request. Otherwise the attribute value will automatically be assigned from the store’s settings.
Important
The WebSiteUrl, DefaultUrl, FailUrl and SuccessUrl parameters must be entered in one domain. For example:

Otherwise it will not be possible to register the store.


After providing details and registering the online store, the merchant will be provided with the following attributes:

  • ShopId - Online store’s identifier for creating the payment page;
  • SecretKey - Unique secret key for creating the payment page;
  • Username - Merchant user’s login. Value is required for the authorisation by token method;
  • Password - Merchant user’s password. Value is required for the authorisation by token method

With these attributes, the merchant gets access to the EMS stage and production environment, which are located at the following addresses:

Stage: https://sb-ms.epayments.com
Production: https://ms.epayments.com

Web-form usage

The merchant can create and send an invoice to the buyer without having to undergo API integration with EMS. This is possible via a special web-form. The web form can be accessed via the following link

https://ms.epayments.com/create-invoice

In the web form, the following fields are available to the merchant:

FieldDescription
Shop IDOnline shop identifier
Shop SecretOnline shop secret key
Order NumberOrder number, which is unique for this online shop
Order NameOrder name (product name)
Order DescriptionShort description of the order
Order AmountThe amount, which will be paid for the order. Decimal separator – dot. No more than 2 characters can be entered after the dot
Payment CurrencyCurrency, which will be used to pay for the order:
- USD (default);
- EUR;
- RUB
Payment Page LanguagePayment Page Language:
- EN (default);
- ES;
- RU
Payer e-mailPayer’s email. Can be field out only if the Integration type = Invoicing

After entering the correct data, a merchant must press Proceed button in order to see the following buttons:

  • Copy Link – copy the link to the payment page;
  • Reload Page – update data in the web form.

The merchant needs to copy the link and sent it to the buyer. Upon clicking on the link the payment page for specific invoice will be opened.

Authorisation

Authorization in EMS can be done one of two ways:

  • Authorization via ShopId;
  • Authorization via access_token.

To work with the payment page, recurrent payments and Direct payments, a ShopId authorization method is used. The auth signature is generated on the merchant side and then transferred to the EMS.

For the API methods, authorization by access_token is used. A token is obtained in response to the POST /token request.

Creating payment

Creating payment

Payment method

EMS allows the merchant to issue invoices, which can be paid for by buyer using the following methods:

  • Bankcard VISA, Maestro or MasterCard;
  • WebMoney wallet;
  • ePayments e-Wallet;
  • Yandex.Money wallet

If required, the merchant can set restrictions for the availability of payment methods. This is done using the gateWayId parameter, which is sent alongside the request to create payment page GET /paymentpage.

Depending on the gateWayId value, the buyer will receive one of the following payment forms:

  • If gatewayId was not transmitted in the request, by default the payment method selection page will open for the buyer:


  • If gatewayId = 1, the payment requisites entry page will open for the client when paying by bank card. This same page is opened when selecting the value “Bankcard” on the payment method selection page:


Buyer’s Email
The Email field is displayed on the payment page only if the merchant did not sent the buyer’s email value in the customerEmail parameter in the GET /paymentpage request. If the parameter was sent, then the “Email” field will not be displayed and the buyer’s notification will be sent to the email, specified by the merchant.

  • If gatewayId = 2, the buyer will first be redirected to the ePayments website to pay the invoice. This same site is opened when selecting the value “ePayments” on the payment method selection page.

  • If gatewayId = 3, the buyer will first be redirected to the WebMoney website to pay the invoice. This same site is opened when selecting the value “WebMoney” on the payment method selection page.

  • If gatewayId = 5, the buyer will first be redirected to the Yandex.Money website to pay the invoice. This same site is opened when selecting the value “Yandex.Money” on the payment method selection page.

Payment creation

The method returns a link via which the online store or buyer can be redirected to the payment page. The method is used for the following payment scenarios Redirect, Iframe and Invoicing.

get
/api/v1/public/paymentpage
Request parameters
shopId
integer
query

Store identifier. Issued to the merchant during registration

orderNumber
string
required
query

Unique invoice number in the online store.
If a payment with this number was already successfully carried out, then future payment attempts will be declined.
Any characters can be entered. Length from 1 to 64 characters

orderSumAmount
number $float
required
query

Payment amount. Separator - decimal point. Allowed number of characters after the decimal point depends on the payment currency (orderSumCurrency) and its digit capacity requirements (in accordance with ISO-4217).
For example, to create an invoice for 10 USD you need to transfer:

  • orderSumAmount = 10.00
  • orderSumCurrency = USD

If an incorrect number of digits is transmitted for the selected currency, the error 2002019 will be returned in the response

orderSumCurrency
string
required
query

Three-letter ISO code of the payment currency

orderName
string
required
query

Payment name

sha512
string
required
query

Result of completion of SHA512 hash function. String is generated by the online store via the following payment form attributes:
shopId;secretKey;orderNumber;orderSumAmount;orderSumCurrency
The attribute separator – semicolon. Spaces between attributes are not permitted

orderDescription
string
query

Order description

gatewayId
integer
query

Payment method identifier:

  • 1 – bank card
  • 2 – ePayments e-Wallet
  • 3 – WebMoney wallet
  • 5 – Yandex.Money wallet

If the parameter is not transmitted, the payment method selection page will open

customerEmail
string
query

Buyer’s email address for receiving payment notifications. If this parameter is transferred, the buyer will not be able to specify or change the email, to which notification with payment status will be sent.
This parameter is mandatory, then transmitting the sendEmail=true parameter.
The method of obtaining buyer’s email is determined by the merchant and is not regulated by EMS

sendEmail
boolean
query

An indicator of whether it is necessary to send an email to the buyer with a request to pay the invoice:

  • true - send it
  • false (default) - do not send it

If sendEmail=true, then the following parameters will become mandatory:

  • customerEmail
  • integrationType = Invoice
shopSuccessUrl
string
query

Page to which the buyer will be redirected if the payment was successfully carried out.
The parameter may be left empty if it was previously provided by the merchant during online store registration

shopFailUrl
string
query

Page to which the buyer will be redirected if an error occurs when carrying out the payment.
The parameter may be left empty if it was previously provided by the merchant during online store registration

shopDefaultUrl
string
query

Page to which the buyer will be returned if they have clicked on the “Back to store” button prior to receiving the operation (i.e. the buyer decided not to complete payment).
The parameter may be left empty if it was previously provided by the merchant during online store registration

language
string
query

Payment page language. Possible values:

  • En (default) – English;
  • Ru – Russian;
  • Es – Spanish
shopEmail
string
query

A merchant’s copy of a notification email regarding the final payment status. If the shopEmail parameter was not sent, but the merchant has enabled the option to receive email notifications, then the payment status notification will be sent to MerchantEmail (specified when registering the store)

operationLifeTime
integer
query

Invoice validity period prior to its payment. Displayed in minutes. Values from 1 to 4320 accepted.
This parameter is not mandatory if it was provided earlier by the merchant when registering the online store

integrationType
string
query

Invoice creation method. Possible values:

  • Redirect (default) – redirects;
  • Invoice – creates invoice
saveCard
integer
query

Indicates if the buyer’s bankcard information needs to be saved if the invoice is paid successfully. The value is set as 1 - saving bankcard data (such as card number, CVC and 3ds).
Parameter is sent only for gateWayId = 1.
If the parameter is not sent, then the bankcard will be used only for a one-time payment without saving its data

DMO
boolean
query

Indicates if using the pre-authorization payment option to block funds on the buyer’s bank card and later debit them is available:

  • true - pre-authorization is available, funds can be blocked for the number of days specified in HoldExpDays;
  • false (default) – pre-authorization is not available

The parameter is sent only if integrationType = redirect

holdExpDays
integer
query

The exact number of days during which funds can be blocked on the buyer’s card. Parameter is sent only if DMO = true

autoReturn
boolean
query

Indicates if buyer will be redirected to the URL, specified by the shop, after the invoice is paid:

  • true – buyer will be redirected;
  • false (default) – buyer will not be redirected
merchRefCode
string
query

A dynamic payment descriptor that will appear in the buyer’s bank statement after the payment is completed.
The parameter is sent only if the invoice is paid for with a bankcard.
Only digits and Latin letters can be entered. Length varies up to 6 characters. This is a case-sensitive parameter

cardToken
string
query

A bankcard token, which is used later to fill out data on the payment page if payment is carried out via bankcard

cardHolderName
string
query

Cardholder name. Transmitted only if gateWayId = 1 (payment by bank card). Field length varies from 2 to 100 characters. Only latin letters, spaces and special characters such as - . ' can be used
When transmitting this parameter in GET /paymentpage, the Name field will not be displayed on the payment page.

Request example
curl -X GET "https://ms.epayments.com/api/v1/public/paymentpage?shopId=98&orderNumber=111&orderSumAmount=10.00&orderSumCurrency=USD&orderName=Name&sha512=1DA5F09EC2DC11E1C7034DE50A93311F3C6DB762235F6866C94B45&orderDescription=Description&gatewayId=1&customerEmail=customer%40mail.com&sendEmail=true&shopSuccessUrl=https%3A%2F%2Fshop-name.com%2Fsuccess&shopFailUrl=https%3A%2F%2Fshop-name.com%2Ffailed&shopDefaultUrl=https%3A%2F%2Fshop-name.com%2Ffailed&language=En&shopEmail=shop-name%40mail.com&operationLifeTime=4320&integrationType=redirect&saveCard=1&DMO=true&holdExpDays=1&autoReturn=false&merchRefCode=code12&cardToken=544B0-74A544EAA0-4FA7AB37C9EFE05B7-0F8FF&cardHolderName=NAME%20SURNAME" -H  "accept: application/json"
Responses
result
object

Result array parameters

Show parameters
Response example
{
  "result": {
    "urlToRedirect": "https://ms.epayments.com/p/859f2a8a8e5c4a3084ca6d2373405680"
  }
}

Payment results

After an invoice is paid for, notification with the operation result - a callback, is sent to a merchant, using a previously specified CallbackUrl.


Mandatory Callback parameters:

ParameterTypeDescription
CallbackDatedateTimeDate and time the notification was created in EMS. Transmitted in the format yyyy-mm-ddThh:mm:ss.fffZ
PaymentDatedateTimeDate and time the order payment was confirmed by the buyer (I.e. operationState = done)
Sha512stringResult of completing SHA512 hash function, which necessary to verify the notification. Created as SHA512 from the shopId;secretKey;orderNumber;orderSumAmount;orderSumCurrency string
The attribute separator – a semicolon ;. Spaces between attributes are not permitted
ShopIdintegerOnline store identifier
OperationIdintegerOperation identifier
OrderNumberstringInvoice number in the online store’s system
OrderNamestringOrder name
OrderSum
Amount
decimalOrder amount
OrderSum
Currency
stringThree-letter ISO code of the payment currency
GatewaySum
Amount
decimalAmount debited from the buyer for the selected payment method
GatewaySum
Currency
stringThree-letter ISO code of the payment currency debited from the buyer
ShopSum
Amount
decimalAmount to be credited to the merchant’s account in EMS.
ShopSum
Currency
stringCurrency amount to be credited to the merchant’s account in EMS
OperationStatestringCurrent operation status:
- Rejected;
- Canceled;
- Done
CustomerEmailstringBuyer’s email address for receiving payment notifications
GatewayobjectAn object that contains information about the bankcard holder (who carries out the payment).

Object parameters:
-WalletIdentifier - Buyer’s e-wallet number. Only sent if Name = ePayments or WebMoney;

- Name - payment provider name. Possible values are - Bank Card, ePayments or WebMoney;

- CardHolder - cardholder name. Sent only if Name = Bank Card;

- CardToken - a bankcard token, used to fill in blanks on the payment page if payment is carried out via bankcard;

- PanCodeMasked - masked card number. Provided in format 123456******1234. Sent only if Name = Bank Card;

- ShopGatewayId - online store payment method identifier
OperationTypestringOperation type. Takes the value IncomingPayment - accepting payment
InvoiceExp
DateTime
datetimeInvoice expiration time, after which the invoice can no longer be successfully paid (correlating to the current time in UTC + 0)



Not-Mandatory Callback parameters:

ParameterTypeDescription
Order
Description
stringOrder description
RatestringExchange rate to the currency to be credited. Transmitted in the format "1 currency_debiting = amount_receipt currency_receipt". For instance, “1 USD = 62.6743 RUB” In the receipt amount up to 4 decimal points are displayed after the decimal point
ErrorobjectAn object that contains information about the error. It is returned only for an unsuccessful callback.

Object parameters:
- Code - error code;
- Message - text description
MaxRebill
Attempts
integerThe maximum number of attempts allowed for paying an invoice. Set in the settings of the online store
UsedRebill
Attempts
integerThe number of attempts that were used to pay for the same invoice



Successful request example:

{  
   "ShopSumAmount":616.80,
   "ShopSumCurrency":"RUB",
   "Rate":"1 RUB = 0.0161 USD",
   "PaymentDate":"2019-04-18T13:48:06.33Z",
   "OperationId":21714,
   "OrderName":"Order",
   "OrderDescription":"Description",
   "GatewaySumAmount":1.00,
   "GatewaySumCurrency":"USD",
   "CustomerEmail":"[email protected]",
   "InvoiceExpDateTime":"2019-04-18T14:16:13.6865718Z",
   "MaxRebillAttempts":17,
   "UsedRebillAttempts":1,
   "CallbackDate":"2019-04-18T13:48:15.9537261Z",
   "Sha512":"b9a785648fcf2ecfe742d3affd805d208de5ec62",
   "ShopId":1,
   "OrderNumber":"ED-676-1",
   "OrderSumAmount":10.00,
   "OrderSumCurrency":"USD",
   "OperationState":"Done",
   "Gateway":{  
      "WalletIdentifier":"000-861964",
      "Name":"ePayments",
      "ShopGatewayId":85
   },
   "OperationType":"IncomingPayment"
}



If the payment is successfully processed, a message about the operation’s success will be displayed on the payment page.



The buyer will also receive a corresponding email notification. If in the request body GET /paymentpage the shopEmail parameter was transmitted, a copy of the email notification will be sent to the merchant.



Unsuccessful request example:

{  
   "Rate":"",
   "PaymentDate":"2019-04-18T14:27:17.886Z",
   "OperationId":21721,
   "OrderName":"Order",
   "OrderDescription":"Description",
   "GatewaySumAmount":1.00,
   "GatewaySumCurrency":"USD",
   "CustomerEmail":"[email protected]",
   "InvoiceExpDateTime":"2019-04-18T14:53:15.1797886Z",
   "UsedRebillAttempts":1,
   "CallbackDate":"2019-04-18T14:27:32.3005005Z",
   "Sha512":"1d14a3f04dabac5fcf872b12e4add73a9847c",
   "ShopId":261,
   "OrderNumber":"ED-676-7",
   "OrderSumAmount":1.00,
   "OrderSumCurrency":"USD",
   "OperationState":"Rejected",
   "Gateway":{  
      "WalletIdentifier":"",
      "Name":"WebMoney",
      "ShopGatewayId":111
   },
   "Error":{  
      "Code":9003017,
      "Message":"Invoice rejected by payer"
   },
   "OperationType":"IncomingPayment"
}



If the payment is not successfully processed, a message about the payment decline will be displayed on the payment page.



The buyer will also receive a corresponding email notification. If in the GET /paymentpage request body the shopEmail was transmitted, a copy of the email notification will be sent to the merchant.

Redirect

Redirect

Available operations

Redirect integration type is suitable for merchants who do not need to add payment forms to their online stores. However, in that case it will be mandatory for their online store to have a payment button, which after clicking the buyer is redirected to the EMS page.

When working with Redirect:

  • invoice payment parameters are created in the online store;
  • payment is carried out by EMS;
  • the buyer is automatically redirected from the online store to the EMS payment page.


Redirect integration also allows the merchant to access the following operations:

Payment scenario

For Redirect the workflow is organized in accordance with the following algorithm:

  1. The buyer selects goods or services in the online store, creates a basket and clicks the payment button.
  2. The online store transmits the purchase parameters to EMS (price, currency, description etc).
  3. A payment link is created in EMS.
  4. The buyer follows the link.
  5. A payment page opens in EMS where the buyer can carry out the payment.

The time to carry out the operation must be clarified with the EMS support team.

Iframe

Iframe

Available operations

Iframe integration type is suitable for merchants who do not want to redirect buyers to third-party websites and wish to carry out payment within their online store. To access this method an additional integration is required from the merchant.

When working with Iframe:

  • parameters for invoice payment are created in the online store;
  • payment takes place in the online store;
  • the buyer remains in the online store for payment of the invoice.


Iframe integration also allows merchant to access the following operations:

Payment scenario

For Iframe the workflow is organized in accordance with the following algorithm:

  1. The merchant creates the payment page for their online shop.
  2. The buyer selects the goods or service in the online store, adds them to the basket and clicks on the pay button.
  3. The online store transmits the purchase parameters to EMS (price, currency, description etc.).
  4. A payment link is created in EMS.
  5. The buyer follows the link.
  6. In the online store a payment page opens where the buyer carries out payment.

The time to carry out the operation must be clarified with the EMS support team.

Site settings

Within the framework of iframe the merchant must embed JavaScript in his/her online store to initialise the payment page. The code may be placed in any part of the html page:

<script src="https/ms.epayments.com/ems-paymentPage.js"></script>

Support older browsers the merchant must enable polyfills for Promise and Fetch API methods:

<script src="https/ms.epayments.com/ems-paymentPage.with-polyfill.js"></script>

To use his/her polyfills the merchant must first enable polyfills and then upload the payment page integration script.


PaymentPage class
After implementing this script the EMS object will be available to the merchant, as well as the EMS.PaymentPage class. Below an abstract description of the EMS.PaymentPage class is presented.

interface Options {
  apiUrl?: string;
}

abstract class PaymentPage {
    constructor(paymentInfo: PaymentInfo | string, options: Options = {});
    async init(mountNode: Element | string, {
        submitButton: Element | string,
        styles: Theme,
        mode: 0 | 1
    }): Promise<any>;
    async destroy(): Promise<any>;
    addEventListener(eventName: string, fn);
    removeEventListener(eventName: string, fn);
    triggerEvent(eventName: string, data: any);
}
Class methodsDescription
constructorConstructor which takes the following arguments:
- paymentInfo — payment parameters. If it is in string format, it is taken as a prepared url for the payment page request. For the parameter descriptions see below;
- options — constructor options. For example, options.apiUrl — a basic url for requesting the payment page. The parameter can be ignored if paymentInfo is a string.
initMethod for initialization and embedment of the payment page:
- submitButton - an element or selector of an element that initiates the form sending on click;
- styles - a stylization of payment form fields. The value set is equal to the Theme interface;
- mode - iframe mode: 0 - standard mode (default); 1 - customization
destroyMethod for dismantling the payment page
addEvent
Listener
Method for subscribing to payment page events. Non-mandatory
removeEvent
Listener
Method for unsubscribing from payment page events




PaymentInfo interface
The PaymentInfo interface contains the same parameters as the method for calling the payment page GET /paymentpage:

interface PaymentInfo {
  shopId: number;
  orderNumber: string;
  orderSumAmount: string;
  orderSumCurrency: string;
  orderName: string;
  sha512: string;
  gatewayId?: number;
  orderDescription?: string;
  customerEmail?: string;
  shopSuccessUrl?: string;
  shopFailUrl?: string;
  shopDefaultUrl?: string;
  language?: string;
  operationLifetime?: number;
}
ParameterDescription
shopIdOnline store identifier provided during registration
orderNumberUnique invoice number in the online store
orderSum
Amount
Payment amount. Separator - decimal point. Up to 2 decimal points are allowed after the separator
orderSum
Currency
Three-letter payment currency ISO code
orderNamePayment name
sha512Result of completion of SHA512 hash function. String is generated by the online store via the following payment form attributes:shopId;secretKey;orderNumber;orderSumAmount;orderSumCurrency
The attribute separator – a semicolon. Spaces between attributes are not permitted
gatewayIdPayment method identifier. Takes the only value gatewayId = 1 (bank card).
orderDescriptionOrder description (for example, list of goods)
customerEmailEmail address of the buyer for receiving payment notifications
shopSuccessUrlPage to which the buyer will be redirected if the payment is successfully carried out.
Parameter non-mandatory for completion if it was previously provided by the merchant when registering the online store
shopFailUrlPage to which the buyer will be redirected if an error occurs when carrying out the payment.
The parameter is not mandatory for completion if it was previously provided by the merchant when registering the online store
shopDefaultUrlPage to which the buyer will be returned if clicking on the “Back to store” button prior to receiving the result (i.e. the buyer declined to pay upon his/her own initiative).
The parameter is not mandatory for completion if it was previously provided by the merchant when registering the online store
languagePayment page language. Possible values:
- En (default) – English;
- Ru – Russian;
- ES – Spanish
operation
LifeTime
Invoice validity period prior to its payment. Displayed in minutes. Values from 1 to 4320 accepted.
This parameter is not mandatory if it was provided earlier by the merchant when registering the online store




init method
When initialising payment the merchant must create an example of EMS.PaymentPage class and call the EMS.PaymentPage::init method. As an argument the method accepts links to html-elements or its corresponding selector:

<div id="payment-page"></div>

If the payment page is initialized immediately when uploading the html-page the merchant must be certain that at the moment of initialization the element for embedding iframe was added to DOM.


addEventListener method
After successfully initialising, the merchant can subscribe to possible payment page events by using the EMS.PaymentPage::addEventListener method. Subscription to these events is not mandatory.

Javascript code for ECMAScript 6+ versions:

(async function(){
   // page –class example
   const page = new EMS.PaymentPage(   {
      shopId:123,
      orderNumber:'456',
      orderSumAmount:'44.56',
      orderSumCurrency:'USD',
      gatewayId:1,
      language:'en',
      orderName:'Order name',
      orderDescription:'Order description',
      operationLifetime:30,
      sha512:'280e4f7fef0c2dc1524cc7c5de4964eaf398fe'
   });
   try   {
      // page monitoring for element with id="payment-page"
      const result = await page.init('#payment-page');
      console.log(result);
      // subscription to payment change status
      page.addEventListener('status:change', console.log);
   }   catch(e)   {
      console.error(e);
   }
})()


Javascript code for ECMAScript 5 version:

(function(){
    var page = new EMS.PaymentPage({
        shopId: 123,
        orderNumber: 456,
        orderSumAmount: 44.56,
        orderSumCurrency: 'USD',
        gatewayId: 1,
        language: 'en',
        orderName: 'Order name',
        orderDescription: 'Order description',
        operationLifetime: 30,
        sha512: '280e4f7fef0c2dc1524cc7c5de4964eaf398fe'
    });

    page.init('#payment-page')
        .then(function(result){
            console.log(result);
            page.addEventListener('status:change', function(val){
                console.log(val.status);
            });
        })
        .catch(function(e){
            console.error(e);
        })
})()




Available events

EventsDescriptionInformation
status:changeEvent to receive final payment status. At present the merchant may remove the iframe display and show the client additional informationstatus: ‘DONE’ or ‘REJECT’

Customisation

The merchant can customize the iframe in accordance with the design of their online store (hereinafter - customisation).

Customisation is available only for invoices that will be paid for by bank card. This means that a custom design can be applied to the following fields of the payment form:

  • email – buyer(payer) email address;
  • card number – card full number;
  • expired date – card expiration date;
  • cvc – CVC code;
  • card holder – cardholder first and last name.

To access customisation features, the merchant needs to define the following parameters in the init method when creating the page:

ParameterSet valueDescription
mode1Iframe work mode. For customization accepts the value = 1
submitButtonhtml-element or selector of an elementThe element initiates submission of a form on click. At the time of creation of the payment page, this element must be present in the DOM structure
stylesThemeInterface to make changes in the basic style of fields.




Theme interface
While working with customization it is possible to change basic style of fields through the Theme interface:

interface Theme {
    errorColor: string;
    blurColor: string;
    focusColor: string;
    textColor: string;
    backgroundColor: string;
    fontFamily: string;
    template: string;
    placeholderColor: string;
    gap: string;
}
AttributeDescriptionValue
errorColorText color and color of the line located below the field (in case of an error)#eb5557
blurColorColor of the line located below the field (in inactive state)#d7e0ea
focusColorColor of the line located below the field (when inputting a value in the field)#286ef2
textColorColor of the text that have been inputted in the field#1a1b1f
background
Color
Iframe background color#ffffff
fontFamilyIframe form font“’PT Sans’, sans-serif”
templateFields layout template. Fields visually represented as a table where rows are separated from each other by the ' symbol.
Each line should contain the same number of elements. For example, 4 lines of 2 elements or 3 lines of 3 elements, etc.
To arrange for one field to be in one line, the field value must be duplicated in accordance with the number of elements.
For example, in the default setting, the fields are arranged in 4 lines with 2 elements in each. In this case, in the first, third and fourth line contains one field each, and the second line - two fields
‘card-number card-number’
‘exp-date cvc’
‘card-holder card-holder’
‘email email’
placeholder
Color
The color of the text that is used as an example of the inputted value (placeholder)#76869a
gapThe distance between the columns and the fields.
The first value determines the vertical distance between the fields, the second value determines the horizontal distance between the columns
0 15px

Invoicing

Invoicing

Available operations

Invoicing integration type is suitable for merchants whose buyers order goods or services without the online store’s participation (for example, via an operator). In this instance, the online store does not need to have cart and payment buttons.

When working with Invoicing:

  • parameters for invoice payment are created by the merchant;
  • payment is carried out by EMS;
  • the buyer goes to the EMS page him/herself via the link from the merchant.

Invoicing integration also allows merchant to access the following operations:

Payment scenario

For Invoicing the workflow is organised in accordance with the following algorithm:

  1. The buyer informs the merchant that he/she wishes to acquire goods or services.
  2. The merchant creates invoice parameters him/herself (price, currency, description etc.) and sends them to EMS.
  3. In response a created link to pay the invoice is received, which the merchant sends to the buyer.
  4. The buyer receives a link (directly from the merchant or via email-notification) and opens the payment page.
  5. A payment page opens in EMS where the buyer can carry out the payment.

The time to carry out the operation must be clarified with the EMS support team.

Creating an e-mail

When working with Invoicing, the merchant can send an email notification about the invoice issued to the buyer. An email is sent after forming a link to the payment page (GET /paymentpage method) if the following parameters were passed in the URL request:

  • customerEmail - customer email address;
  • sendEmail - an indicator of whether it is necessary to send a notification. Must be = true.
Note
The method for obtaining the buyer's email is determined by the merchant and is not regulated by EMS. The email address must be obtained before sending create a link request.

After the link is formed, an email with the request to proceed to the invoice payment page will be sent to the buyer.

The notification language depends on which language parameter was sent during the link generation request. If no such parameter was sent, the notification will be sent in English, by default.

The payment button in the email notification is valid for the duration of the operationLifeTime time. It is sent by the merchant during registration or when creating the payment page link.

Direct

Direct

Available operations

Direct integration type is suitable for merchants who uses their own payment form when interacting with the buyer. In accordance with the PCI DSS regulations, merchants who intended to use this integration type first must fill out the SAQ form and go through ASV scanning.

When working with Direct:

  • parameters for invoice payment are created in the online store;
  • the buyer enters payment data;
  • payment is carried out by EMS;
  • EMS payment page is not used then paying the invoice.


The Direct integration also allows merchant to access the following operations:

Payment scenario

For Direct the workflow is organized in accordance with the following algorithm:

  1. The buyer selects goods or services in the online store, creates a basket and clicks the payment button.
  2. The buyer enters payment details.
  3. The online store transmits the purchase parameters to EMS (price, currency, description etc).
  4. EMS performs the authentication of the online store and carries out the payment.

Payment creation

This method is intended for creating payments using the Direct payment scenario. In response to this method, the merchant will receive:

  • link to which the merchant can redirect their buyers to confirm payment. After clicking on the link, the buyer will be redirected to a page to enter a confirmation code (3-D Secure);
  • or the result of the operation (if the 3-D Secure code was not required).

If the merchant did not receive a response to the submitted request, it is possible to check the current status of the request manually. For this, the merchant needs to re-send the POST/v1/payment request using the same secret, shopId and OrderNumber. In this case, in response to the request, the merchant will receive operation data.

post
/api/v1/payment
Request parameters
Content-type
string
required
header

application/json

Request body
paymentMethod
string

Information about the payment method. Set value is 1 - payment by credit card

Example: 1
paymentMethodData
object

Payment details

Show parameters
paymentInfo
object

Payment processing data

Show parameters
orderNumber
string
required

Unique order number assigned by the online store system

Example: EDF-456-43
orderSumAmount
number $float
required

Payment amount in the online store currency

Example: 50.32
orderSumCurrency
string
required

Three-letter payment currency ISO code

Example: USD
orderName
string
required

Order name

Example: Name
orderDescription
string

Order description

Example: Description
customerEmail
string

Buyer’s email address for receiving payment notifications

language
string

Email notification language. Possible values are EN, RU, or ES

Example: EN
merchRefCode
string

A dynamic payment descriptor that will appear in the buyer’s bank statement after the payment is completed.
The parameter is sent only if the invoice is paid for with a bankcard.
Only digits and Latin letters can be entered. Length varies up to 6 characters. This is a case-sensitive parameter

Example: code12
shopEmail
string

Online store’s email address for receiving payment notifications

saveCard
integer

Indicates if the buyer’s bankcard information needs to be saved if the invoice was paid successfully. The value is set as 1 - saving bankcard data (such as card number, CVC and 3ds).
Parameter is sent only for gateWayId = 1. If the parameter is not sent, then the bankcard will be used only for one-time payment without saving its data

Example: 1
dmo
boolean

Indicates if using the pre-authorisation payment option to block funds on the buyer’s bank card and later debit them is available:

  • true – pre-authorisation is available, funds can be blocked for the number of days specified in the HoldExpDays;
  • false (default) – pre-authorisation is not available
Example: 462
holdExpDays
integer

The exact number of days during which funds can be blocked on the buyer’s card. Parameter is sent only if DMO = true

Example: 10
Request example
{
  "paymentMethod": "1",
  "paymentMethodData": {
    "cardHolderName": "Alex Titmus",
    "cardNumber": "5413330000000019",
    "expMonth": "01",
    "expYear": "20",
    "cvv": "533"
  },
  "paymentInfo": {
    "returnURL": "https://shop-return-url.com"
  },
  "orderNumber": "EDF-456-43",
  "orderSumAmount": "50.32",
  "orderSumCurrency": "USD",
  "orderName": "Name",
  "orderDescription": "Description",
  "customerEmail": "[email protected]",
  "language": "EN",
  "merchRefCode": "code12",
  "shopEmail": "[email protected]",
  "saveCard": "1",
  "dmo": "462",
  "holdExpDays": "10"
}
Responses
result
object

Result object parameters

Show parameters
Response example
{
  "result": {
    "operationId": "46585",
    "state": "Rejected",
    "confirmationURL": "http://example.com",
    "error": {
      "code": "9002000",
      "messages": "The transfer cannot be made. Please contact the support team or try again later"
    }
  }
}

Additionally

Additionally

Rebill

This method is used for re-attempting to pay the invoice. The number of attempted payments is specified by the merchant in the store settings on the EMS side.

Re-bill is available when the following conditions are met:

  • Selected method for invoices = Invoicing;
  • The buyer has a sufficient number of attempts to re-pay;
  • Operation Status = Rejected;
  • The lifetime of the OperationLifeTime invoice has not expired.

If these conditions are met, the “Try again” button will be displayed to the buyer in the transaction result form. Upon clicking on this button, the buyer will be redirected back to the payment page.


The merchant can made the final decision on invoice processing only after receiving a callback with one of the following statuses:

  • Done
  • Canceled
  • Rejected and error code = 2002016 (Invoice expired)
post
/api/v1/public/rebill
Request parameters
Authorisation
string
required
header

Shop_token, which is obtained in the GET /paymentpage response

Content-type
string
required
header

application/json

Request example
curl -X POST "https://ms.epayments.com/api/v1/public/rebill" -H  "accept: application/json" -H  "Authorisation: Bearer VBJKL1liFkOWD4J90qwpUxwMesEJ6sot="
Responses
result
object

Successful response parameters

Show parameters
Response example
{
  "result": {
    "urlToRedirect": "https://ms.epayments.com/p/859f2a8a8e5c4a3084ca6d2373405680"
  }
}

Pre-authorisation

A pre-authorisation payment is one of possible methods for accepting payments via bank cards. This method includes pre-emptively blocking funds on the buyer’s card for a certain number of days (HoldExpDays) and debiting/charging them after, at the request of an online store.

To use this method, the merchant needs to send the HoldExpDays parameter to the EMS during registration process, and specify the number of days during which the funds on the buyer’s card can remain blocked. The period can vary from 1 to 28 days (the default is 28 days).

Pre-authorisation payment method only available for those merchants who are using Redirect.

After activating this service, the merchant must:

  1. Create a link to the GET /paymentpage payment page and send the parameter DMO = true in the request body. If the DMO parameter is not sent or sent as DMO=false, pre-authorisation payment will not be available.

  2. After blocking customer’s funds:

    • call the POST /CardCharge method in order to debit a previously blocked amount from the client’s card before HoldExpDays has expired;
    • or call the POST /CardCancel method to return funds to the client’s card if HoldExpDays has not expired yet.

Recurrent payments

Recurrent payments are regularly executed payments, which use data from saved bankcards. Payments are initiated on the merchant’s side, without direct participation of the buyer.

Payment conditions
Working with recurrent payments is possible if the following conditions are met:

  • The merchant has access to the operation (access is obtained via online store settings on the EMS side).
  • The first payment via bank card was initiated by the buyer and it was successful.
  • The currency of all subsequent payments is the same as the currency of the original payment (the value of the GatewaySumCurrency parameter) made via saved bankcard.


Payment scheme
Recurrent payments are executed in accordance with the following scheme:

  1. The merchant calls the payment page via the GET /paymentpage method and pass the saveCard = 1 (saving a bank card) parameter in the request body.
  2. The buyer goes to the payment page and successfully pays the invoice with a bankcard.
  3. The merchant receives a callback for a successful transaction. Callback contains the token of the used bankcard.
  4. At the required frequency, the merchant sends the POST /recurrent request and pass the previously received card’s token and the transaction currency in the request body. Transaction currency of subsequent transactions must be the same as the first, original, payment currency.
  5. An amount specified in the transaction is automatically debited from the saved buyer’s bankcard.
  6. The buyer and the merchant receive notifications regarding the transaction.



Card’s token
Bankcard token is valid for the duration of 1 year, starting from the moment it was sent in the callback for a first successful payment.
post
/api/v1/payment/recurrent
Request body
shopId
integer

Identifier of the online store, for which a recurring payment is required

Example: 1
cardToken
string

Token of a previously saved bankcard, from which funds will be charged

Example: dfgtey56er6efdfg56464576
orderNumber
string

Unique order number assigned by the online store system

Example: 56
orderName
string

Order name

Example: Name
orderSumAmmount
number $float

Payment amount

Example: 50.10
orderSumCurrency
string

Three-letter ISO code of the payment currency. Must be the same as in the original payment

Example: usd
customerEmail
string

Buyer’s email address for receiving payment notifications

shopEmail
string

Online store’s email address for receiving payment notifications

orderDescription
string

Order description

Example: Purchasing goods
Request example
{
  "shopId": "1",
  "cardToken": "dfgtey56er6efdfg56464576",
  "orderNumber": "56",
  "orderName": "Name",
  "orderSumAmmount": "50.10",
  "orderSumCurrency": "usd",
  "customerEmail": "[email protected]",
  "shopEmail": "[email protected]",
  "orderDescription": "Purchasing goods"
}
Responses
result
object

Result array parameters

Show parameters
Response example
{
  "result": {
    "operationId": "8965"
  }
}

One click payment

The merchant can use obtained card token to pre-fill certain fields in the payment form on the payment page. In that case, the customer, when attempting to pay the invoice, will be required to fill only the CVV field. To use this option, the merchant must:

  1. Send a request to the support service to enable “One click payment” option.
  2. Generate a payment page via GET /paymentpage method and transfer the cardToken, with the previously obtained value, parameter in the request body.

Upon clicking on the generated link, the customer will see a data entry form, in which only the three-digit CVC code and email fields (if the merchant has not already filled it when creating the payment page) will be left for the customer to fill. Card number will be displayed too, but in a masked form and it’s field will not be editable.

Managing payment

Managing payment

Obtaining a token

Some API methods require the merchant to pass authorisation and receive a token. The authorisation mechanism is built on the base of OAuth 2.0 protocol (RFC-6749).

The lifetime of the token in the authorisation method is limited, therefore it is necessary to periodically update it or request a new one. To refresh the token, you must use the refresh_token parameter received with the access_token.

The same method is used to receive and update token - POST /api/v1/oauth/token, but with different request parameters are submitted:

  • password - to receive token;
  • refresh_token - to refresh token
post
/api/v1/oauth/token
Request parameters
Content-Type
string
required
header

application/x-www-form-urlencoded

Request body
grant_type
string
required
Possible values
username
string
required

Login issued to the merchant after entering an agreement with EMS

Example: ShopName
password
string
required

Password issued to the merchant after entering an agreement with EMS

Example: secretKey
Request example
curl -X POST "https://ms.epayments.com/api/v1/oauth/token" -H  "accept: application/json" -H  "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&username=ShopName&password=secretKey"
Responses
token_type
string
required

Token type. Value is always set as Bearer

Example: bearer
access_token
string
required

A token which the EMS client can use to access API methods

Example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ3UPmvzVLKraT43Dm5EkPaYT
expires_in
integer
required

Token validity period. Takes the value of 3600. Displayed in seconds

Example: 3600
refresh_token
string

Value which can be used to update the access_token without transmitting the username and password in the authorisation method body. Obtained in the response body only is grant_type=password was passed

Example: CfDJ8AyUslu18k5GgMgSqVSa8fGVfprnTckhalLW-PrbuidmBf_
Response example
{
  "token_type": "bearer",
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ3UPmvzVLKraT43Dm5EkPaYT",
  "expires_in": "3600",
  "refresh_token": "CfDJ8AyUslu18k5GgMgSqVSa8fGVfprnTckhalLW-PrbuidmBf_"
}

List of operations

This method is used to obtain a list of operations carried out by the merchant’s clients. By default, the merchant receives a list of all clients’ operations for the past 7 days.

Prior to sending the request the merchant must login using his/her login and password via the authorisation method.

get
/api/v1/operation
Request parameters
fromDate
string $date-time
query

Start date from which the operations list will be received. By default, returns operations for the past 7 days. Provided in yyyy-mm-dd format

toDate
string $date-time
query

End date of the operations received in the list. By default, this is the date the request is being made. Provided in yyyy-mm-dd format

operationId
integer
query

Operation identifier set by EMS

externalId
string
query

Operation identifier set by the payment provider

operationType
string
query

Operation type:

  • IncomingPayment - accepting payment;
  • Refund - payment refund;
  • DualMessageOperation - pre-authorised payment;
  • Recurrent - recurrent payment
bin
string
query

First 6 numbers of the bankcard used in the operation

shopName
string
query

Store name

gatewayName
string
query

Payment method name:

  • Bank Card – via bankcard;
  • Epayments – ePayments e-Wallet;
  • Paymaster24 – via WebMoney wallet;
  • YandexMoney – via YandexMoney wallet
fromAmount
number $float
query

Amount sent. Separator- decimal point. Up to 2 digits can be entered after the decimal point

toAmount
number $float
query

Amount received. Separator- decimal point. Up to 2 digits can be entered after the decimal point

fromCurrency
string
query

Currency to be debited. Displayed in three-letter ISO format

toCurrency
string
query

Currency to be received. Displayed in three-letter ISO format

operationState
string
query

Operation status:

  • Open
  • Canceled
  • Rejected
  • Confirmed
  • Accepted
  • Approved
  • Done
  • WMA
  • Waiting for Charge
shopId
integer
query

Store identifier. Issued to the merchant during registration

orderNumber
string
query

Unique online store invoice number

lastDigits
string
query

Last 4 digits of the bankcard used during the operation

Authorization
string
required
header

Bearer access_token, where the access_token is an access key, obtained in the request response during authorisation

Content-type
string
required
header

application/json

Request example
curl -X GET "https://ms.epayments.com/api/v1/operation?fromDate=2018-09-25&toDate=2018-10-25&operationId=34356&externalId=56577&operationType=IncomingPayment&bin=412305&shopName=Shop%20Name&gatewayName=Bank%20card&fromAmount=3.86&toAmount=2.96&fromCurrency=eur&toCurrency=usd&operationState=Done&shopId=98&orderNumber=558965&lastDigits=6543" -H  "accept: application/json"
Responses
result
object

Successful response parameters

Show parameters
Response example
{
  "result": {
    "operations": [
      {
        "creationDate": "2018-09-25T12:47:48.927",
        "id": "9537",
        "externalId": "payment_55",
        "operationType": "Refund",
        "shopName": "Shop Name",
        "gatewayName": "Bank Card",
        "fromAmount": "10.50",
        "fromCurrency": "USD",
        "toAmount": "09.50",
        "toCurrency": "EUR",
        "state": "Done",
        "cardId": "541333******0019",
        "shopId": "261",
        "orderNumber": "261_25_09_2018_001"
      }
    ]
  }
}

Invoice cancellation

This method is used for cancelling a created invoice. A cancellation request can only be sent for unpaid invoices in a State = New or Open. If the invoice has already been paid, the request for cancellation will be declined.

Before sending the request the merchant must login with their username and password via the authorisation method. If the operation is successfully cancelled the merchant will be sent Callback and/or an email notification.

post
/api/v1/payment/cancel
Request parameters
Authorization
string
required
header

Bearer access_token, where the access_token is an access key, obtained in the request response during authorisation

Content-type
string
required
header

application/json

Request body
shopId
integer
required

Online store identifier

Example: 1
orderNumber
string
required

Unique invoice number in the online store for which the refund is to be made.

When the shopId and orderNumber parameters are transmitted, the operationId parameter is not mandatory

Example: 398314
Request example
{
  "shopId": "1",
  "orderNumber": "398314"
}
Responses
result
object

Successful response parameters

Show parameters
Response example
{
  "result": {
    "operationId": "8951",
    "operationState": "Canceled"
  }
}

Payment refund

This method allows to refund a payment which was carried out by bankcard. The refund is carried out only for a successfully paid operation for which operationState = done. Refund amount and currency must match the payment amount (i.e. partial refund is not possible).

Prior to sending the request the merchant must login via the authorisation method. Regardless of the operation processing status, after sending the request and receiving a response, the merchant will receive a callback.

post
/api/v1/payment/card/refund
Request parameters
Authorization
string
required
header

Bearer access_token, where the access_token is an access key, obtained in the request response during authorisation

Content-type
string
required
header

application/json

Request body
operationId
integer
required

Operation identifier for EMS for which the refund must be made. The identifier is received in Callback or in the GET /operation response.

When the operationId parameter is transmitted, the parameters shopId and orderNumber are not mandatory

shopId
integer
required

Unique store identifier. Issued to the merchant when registering online store.

When the shopId and orderNumber parameters are transmitted, the operationId parameter is not mandatory

Example: 105
orderNumber
integer
required

Unique invoice number in the online store for which the refund is to be made.

When the shopId and orderNumber parameters are transmitted, the operationId parameter is not mandatory

Example: 365
amountToRefund
number $float
required

The refund amount in the payment currency. The amount value must match the GatewaySumAmount value received in a Callback

Example: 80
cause
string

Reason for refund

Example: Incorrect payment details
Request example
{
  "operationId": 0,
  "shopId": "105",
  "orderNumber": "365",
  "amountToRefund": "80",
  "cause": "Incorrect payment details"
}
Responses
result
object

Successful response parameters

Show parameters
Response example
{
  "result": {
    "operationId": "1366"
  }
}

Card charge

This method is used in the payment pre-authorisation framework.

To successfully charge or debit charge the blocked funds from the client’s card, the merchant must call the cardCharge method before the HoldExpDays time expires. Upon initiating an operation, the merchant must specify the amount to be debited. The said amount can:

  • match the amount blocked;
  • be less than the amount blocked;
  • exceed the amount blocked, but no more than by 10%.
Available amount
Only one debit operation can be initiated for a single pre-authorisation request. This means, that even if the amount debited is less than the amount blocked, the merchant will not be able to submit an additional charge request for this particular operation.
post
/api/v1/payment/card/charge
Request parameters
Authorization
string
required
header

Bearer access_token, where the access_token is an access key, obtained in the request response during authorisation

Content-Type
string
required
header

application/x-www-form-urlencoded

Request body
operationId
integer
required

Operation identifier for which the blocked funds must be debited from the buyer’s card. When the operationId parameter is transmitted, the parameters shopId and orderNumber will not be transmitted

shopId
integer
required

Merchant’s store identifier. When the shopId parameter is transmitted, the operationId parameter will not be transmitted

Example: 10
orderNumber
string
required

Unique order number, assigned by the online store system. When the orderNumber parameter is transmitted, the operationId parameter will not be transmitted

Example: 5673
chargeAmount
number $float
required

Debit amount

Example: 55.10
Request example
{
  "operationId": 0,
  "shopId": "10",
  "orderNumber": "5673",
  "chargeAmount": "55.10"
}
Responses
result
object

Result object parameters

Show parameters
Response example
{
  "result": {
    "operationId": "6678"
  }
}

Pre-authorisation cancel

This method is used in the payment pre-authorisation framework.

During the HoldExpDays time, the merchant may choose to unblock funds on the client’s card. In such case, the buyer will receive the previously blocked amount back, in full.

After the block is cancelled, the corresponding email notification will be sent to the buyer, the merchant will receive an email and/or callback (depending on the store settings) notification as well.

The block can also be cancelled automatically after the HoldExpDays period has expired, provided that merchant did not send a request for debit or cancellation during the specified period.

post
/api/v1/payment/card/cancel
Request parameters
Authorization
string
required
header

Bearer access_token, where the access_token is an access key, obtained in the request response during authorisation

Content-Type
string
required
header

application/x-www-form-urlencoded

Request body
operationId
integer
required

Operation identifier for which the blocked funds must be debited from the buyer’s card. When the operationId parameter is transmitted, the parameters shopId and orderNumber will not be transmitted

shopId
integer
required

Merchant’s store identifier. When the shopId parameter is transmitted, the operationId parameter will not be transmitted

Example: 10
orderNumber
string
required

Unique order number assigned by the online store system. When the orderNumber parameter is transmitted, the operationId parameter will not be transmitted

Example: 5673
Request example
{
  "operationId": 0,
  "shopId": "10",
  "orderNumber": "5673"
}
Responses
result
object

Result object parameters

Show parameters
Response example
{
  "result": {
    "operationId": "6678"
  }
}

Callback

Callback

EMS Callback

Callback – is an EMS service which sends a notification with the operation result to the CallbackUrl.

EMS sends a HTTP POST request to the online store’s CallbackUrl. If the online store returns 200 OK status, then EMS will receive callback and stop trying to call the handler.

In the absence of a successful response the EMS server will continue to send requests with the following intervals: 1 min, 5 min, 5 min, 10 min, 1 hour, 24 hours. If after 24 hours response was not received, EMS will cease sending requests. If the online store did not receive callback, it can manually send callback for each operation.

Invoice cancellation

Below the Callback is described which sends a notification of the invoice cancellation results to the CallbackUrl.


Mandatory callback parameters:

ParameterTypeDescription
OperationIdintegerOperation identifier
OrderNamestringOrder name
GatewaySum
Amount
decimaAmount debited from the buyer for the selected payment method
GatewaySum
Currency
stringThree-letter currency code debited from the buyer
CallbackDatedateTimeDate and time notifications created in EMS. Transmitted in yyyy-mm-ddThh:mm:ss.fffZ format
PaymentDatedateTimeDate and time of operation cancellation (i.e. operationState = canceled)
Sha512stringResult of completing SHA512 hash function, which necessary to verify the notification. Created as SHA512 from the shopId;secretKey;orderNumber;orderSumAmount;orderSumCurrency string
ShopIdintegerOnline store identifier
OrderNumberstringInvoice number in the online store system
OrderSum
Amoun
decimalOrder amount
OrderSum
Currency
stringThree-letter order currency ISO code
OperationStatestringCurrent operation status = Canceled
GatewayobjectAn object that contains information about the bankcard holder (who carries out the payment).

Object parameters:
- Name - payment provider name. Possible values are - Bank Card, ePayments;

- ShopGatewayId - online store payment method identifier
ErrorobjectResponse description.
Object parameters:
- Code - Response code. If invoice successfully cancelled the code 2002017 will be sent;

- Message - text description



Not-Mandatory Callback parameters:

ParameterTypeDescription
ratestringExchange rate for the currency to be credited (if available)



Successful cancellation example:

{  
   "OperationId":9786,
   "OrderName":"Name",
   "Rate":"",
   "CallbackDate":"2018-10-08T11:40:20.7255414Z",
   "PaymentDate":"2018-10-08T11:40:13.447",
   "Sha512":"8635401afd76380fd8f8d6dab064a4626cfe54c55857f2c405d9550",
   "ShopId":261,
   "OrderNumber":"141",
   "OrderSumAmount":1000.00,
   "OrderSumCurrency":"RUB",
   "OperationState":"Canceled",
   "Gateway":{  
      "Name":"Bank card",
      "ShopGatewayId":38
   },
   "Error":{  
      "Code":2002017,
      "Message":"Operation canceled"
   },
   "OperationType":"IncomingPayment"
}



Unsuccessful cancellation example:

{  
   "OperationId":9179,
   "OrderName":"Name",
   "GatewaySumAmount":100.00,
   "GatewaySumCurrency":"USD",
   "Rate":"",
   "CallbackDate":"2018-09-13T09:24:42.5863503Z",
   "PaymentDate":"2018-09-13T09:24:27.523",
   "Sha512":"6218e2a6a1cf31cc63c6725becd1c9d8cde4a2839c2d1ef74",
   "ShopId":139,
   "OrderNumber":"3301",
   "OrderSumAmount":100.00,
   "OrderSumCurrency":"USD",
   "OperationState":"Canceled",
   "Gateway":{  
      "Name":"Bank card",
      "ShopGatewayId":38
   },
   "Error":{  
      "Code":2002016,
      "Message":"Invoice expired"
   }
}

Payment refund

Below the Callback is described which sends a notification about the payment refund result to the CallbackUrl. This callback is initialized when the following conditions are met:

  • the payment’s final status = Done or Rejected;
  • operation type = Refund.


Mandatory callback parameters:

ParameterTypeDescription
CallbackDatedateTimeData and time the notification was created in EMS. Transmitted in yyyy-mm-ddThh:mm:ss.fffZ format
PaymentDatedateTimeDate and time the payment refund was confirmed by the purchaser (when operationState = done or rejected)
Sha512stringResult of completing SHA512 hash function, which necessary to verify the notification. Created as SHA512 from the shopId;secretKey;orderNumber;orderSumAmount;orderSumCurrency string. The attribute separator – a semicolon ";". Spaces between attributes are not permitted
ShopIdintegerOnline store identifier
IncomingPayment
OperationId
integerPayment receipt operation identifier for which the refund was initiated
OrderNumberstringInvoice number within the online store’s system
OrderSumAmountdecimalOrder amount
OrderSumCurrencystringThree-letter order currency ISO code
RefundOperationIdintegerRefund operation identifier
RefundedGateway
SumAmount
decimalAmount which was refunded to the purchaser. Include fees. Transmitted only in case of successful refund
RefundedGateway
SumCurrency
stringThree-letter ISO currency code of the purchaser’s refund. Transmitted only in case of successful refund
RefundedShop
SumAmount
decimalAmount which was refunded by the online store. Does not include fees. Transmitted only in case of successful refund
RefundedShop
SumCurrency
stringThree-letter order currency ISO code of the online store’s refund currency. Transmitted only in case of successful refund
InitiatedBystringRefund operation initiator:
- Merchant – refund initiated be the merchant;
- Operator – refund initiated by the EMS operator
RefundCausestringUser comments left in the refund request
OperationStatestringCurrent refund operation status:
- Rejected;
- Done
GatewayobjectAn object that contains information about the bankcard holder (who carries out the payment).

Object parameters:
- Name - payment provider name. Possible values are - Bank Card, ePayments or PayMaster24;

- CardHolder - cardholder name. Sent only if Name = Bank Card;

- PanCodeMasked - masked card number. Provided in format 123456******1234. Sent only if Name = Bank Card;

- CardToken - a bankcard token, used to fill in the blanks on the payment page if payment is carried out via bankcard. Passed only if saveCard = 0 or 1, and state = Done;

- ShopGatewayId - online store payment method identifier
OperationTypestringOperation type. Takes the value Refund



Non-mandatory callback parameters:

ParameterTypeDescription
RefundRatestringExchange rate to the currency to be credited. Transmitted in the format "1 currency_debiting = amount_receipt currency_receipt". For instance, “1 USD = 62.6743 RUB” In the receipt amount up to 4 decimal points are displayed after the decimal point
ErrorobjectAn object that contains information about the error. It is returned only for an unsuccessful callback.

Object parameters:
- Code - error code;
- Message - text description



Example of a successful refund:

{  
   "CallbackDate":"2018-07-11T17:44:19.5457669Z",
   "PaymentDate":"2018-07-11T16:23:03.618",
   "Sha512":"2b57a72a2c07c7e2b04f258736dec937b89e",
   "ShopId":266,
   "IncomingPaymentOperationId":2785,
   "OrderNumber":989818,
   "OrderSumAmount":4400.57,
   "OrderSumCurrency":"RUB",
   "RefundOperationId":2793,
   "RefundedGatewaySumAmount":4400.57,
   "RefundedGatewaySumCurrency":"RUB",
   "RefundedShopSumAmount":69.17,
   "RefundedShopSumCurrency":"USD",
   "RefundRate":"1 USD = 63.6237 RUB",
   "InitiatedBy":"Merchant",
   "RefundCause":"Asked for the manager",
   "OperationState":"Done",
   "Gateway":{  
      "Name":"Bank Card",
      "CardHolder":"ANNA POSH",
      "PanCodeMasked":"431422******0049",
      "ShopGatewayId":68
   },
   "OperationType":"Refund"
}



Example of an unsuccessful refund:

{  
   "CallbackDate":"2018-07-11T14:58:59.4722328Z",
   "PaymentDate":"2018-07-11T14:58:45.024",
   "Sha512":"d3a3356e7c6b2fe0c181e343c69d648f62eed2cb85493fd",
   "ShopId":139,
   "IncomingPaymentOperationId":2780,
   "OrderNumber":8934912131,
   "OrderSumAmount":155.55,
   "OrderSumCurrency":"USD",
   "RefundOperationId":2793,
   "InitiatedBy":"Merchant",
   "RefundCause":"Asked for the manager",
   "OperationState":"Rejected",
   "Gateway":{  
      "Name":"Bank Card",
      "CardHolder":"ANNA POSH",
      "PanCodeMasked":"541333******0019",
      "ShopGatewayId":38
   },
   "Error":{  
      "Code":9000000,
      "Message":"Error on the payment system side"
   },
   "OperationType":"Refund"
}

Pre-authorisation

Below is the description of the Callback which sends a notification of the invoice cancellation results to the CallbackUrl. Using this callback the merchant can determine the validity of saved card data.

Mandatory callback parameters:

ParameterTypeDescription
OperationIdintegerOperation identifier
OrderNameintegerOrder name
GatewaySum
Amount
decimalAmount debited from the buyer for the selected payment method
GatewaySum
Currency
stringThree-letter ISO code of the payment currency debited from the buyer
CustomerEmailstringBuyer’s email address for receiving payment notifications
InvoiceExp
DateTime
datetimeInvoice expiration time, after which the invoice can no longer be successfully paid (correlating to the current time in UTC + 0)
CallbackDatedatetimeDate and time when the notification was created in EMS. Transmitted in the yyyy-mm-ddThh:mm:ss.fffZ format
Sha512stringResult of completing SHA512 hash function, which necessary to verify the notification. Created as SHA512 from the shopId;secretKey;orderNumber;orderSumAmount;orderSumCurrency string
The attribute separator – a semicolon ;. Spaces between attributes are not permitted
ShopIdintegerOnline store identifier
OrderNumberintegerInvoice number in the online store’s system
OrderSum
Amount
decimalOrder amount
OrderSum
Currency
stringThree-letter ISO code of the payment currency
OperationStatestringCurrent operation status:
- Open;
- Canceled;
- Confirmed;
- Accepted;
- Approved;
- Done;
- WMA;
- Waiting for Charge
GatewayobjectAn object that contains information about the bankcard holder who carries out the payment.

Object parameters:
- Name - payment provider name. The value is set as - Bank Card;

- CardHolder - cardholder name;

- CardToken - a bankcard token, used to fill in blanks on the payment page if payment is carried out via bankcard;

- PanCodeMasked - masked card number. Provided in format 123456******1234;

- ShopGatewayId - online store payment method identifier
OperationTypestringOperation type. The value is set as DualMessageOperation - payment pre-authorisation
HoldMadeDatedatetimeDate and time when funds were blocked. Transmitted in the yyyy-mm-ddThh:mm:ss.fffZ format
HoldExpDatedatetimeDate and time when the block on funds will be canceled. Transmitted in the yyyy-mm-ddThh:mm:ss.fffZ format



Not-Mandatory Callback parameters:

ParameterTypeDescription
Order
Description
stringOrder
ErrorobjectAn object that contains information about the error. Is returned only for an unsuccessful callback.

Object parameters:
- Code - error code;
- Message - error description
MaxRebill
Attempts
integerThe maximum number of attempts allowed for paying an invoice. Set in the settings of the online store
UsedRebill
Attempts
integerThe number of attempts that were used to pay for the same invoice



Successful request example:

{  
   "HoldMadeDate":"2019-03-28T15:05:48.038Z",
   "HoldExpDate":"2019-04-06T23:59:00",
   "OperationId":21006,
   "OrderName":"Order name",
   "OrderDescription":"Order description",
   "GatewaySumAmount":100.00,
   "GatewaySumCurrency":"USD",
   "CustomerEmail":"[email protected]",
   "InvoiceExpDateTime":"2019-03-28T15:14:40.9380748Z",
   "MaxRebillAttempts":10,
   "UsedRebillAttempts":2,
   "CallbackDate":"2019-03-28T15:06:02.285279Z",
   "Sha512":"c77e4b7602c307d2bc4c1c981766067739a83ef7",
   "ShopId":251,
   "OrderNumber":"28032019_27",
   "OrderSumAmount":100.00,
   "OrderSumCurrency":"USD",
   "OperationState":"WaitingForCharge",
   "Gateway":{  
      "Name":"Bank card",
      "CardHolder":"NAME SURNAME",
      "CardToken":"07E547D9-586F6A73-F73FBAC0-435ED769",
      "PanCodeMasked":"4314 22** **** 0049",
      "ShopGatewayId":121
   },
   "OperationType":"DualMessageOperation"
}



Unsuccessful request example:

{  
   "HoldMadeDate":"2019-03-28T15:05:48.038Z",
   "HoldExpDate":"2019-04-06T23:59:00",
   "OperationId":21006,
   "OrderName":"Order name",
   "OrderDescription":"Order description",
   "GatewaySumAmount":100.00,
   "GatewaySumCurrency":"USD",
   "CustomerEmail":"[email protected]",
   "InvoiceExpDateTime":"2019-03-28T15:14:40.9380748Z",
   "MaxRebillAttempts":10,
   "UsedRebillAttempts":2,
   "CallbackDate":"2019-03-28T15:06:02.285279Z",
   "Sha512":"c77e4b7602c307d2bc4c1c981766067739a83ef7",
   "ShopId":251,
   "OrderNumber":"28032019_27",
   "OrderSumAmount":100.00,
   "OrderSumCurrency":"USD",
   "OperationState":"WaitingForCharge",
   "Gateway":{  
      "Name":"Bank card",
      "CardHolder":"NAME SURNAME",
      "PanCodeMasked":"4314 22** **** 0049",
      "ShopGatewayId":121
   },
   "Error":{  
      "Code":9003017,
      "Message":"Invoice rejected by payer"
   },
   "OperationType":"DualMessageOperation"
}

Sending of callback

EMS sends a HTTP POST request to the online store’s CallbackUrl. If the online store returns 200 OK status, then EMS will receive callback and stop trying to call the handler.

In the absence of a successful response the EMS server will continue to send requests with the following intervals: 1 min, 5 min, 5 min, 10 min, 1 hour, 24 hours. If after 24 hours response was not received, EMS will cease sending requests.

If the online store did not receive callback, it can manually send callback for each operation. The request can be sent an unlimited number of times at any time after completing an operation (receiving a payment or refund).

If callback request was sent manually, the automatic sending of callback for the given operation stops.

post
/api/v1/callback/operation/{id}
Request parameters
id
integer
required
query

Operation identifier issued by EMS, for which a callback will be sent

Authorization
string
required
header

Bearer access_token, where the access_token is an access key, obtained in the request response during authorisation

Content-Type
string
required
header

application/x-www-form-urlencoded

Request example
curl -X POST "https://ms.epayments.com/api/v1/callback/operation/{id}?id=65" -H  "accept: application/json"
Responses
result
object

Result array parameters

Show parameters
Response example
{
  "result": {
    "operationId": "6678",
    "callbackResponseCode": "200",
    "responseDate": "2018-08-02T13:12:30.3807367Z"
  }
}

Guidebooks

Guidebooks

Glossary

TermDefinitions
Buyer(Payer)The person paying for the goods or services in the merchant’s online store
CallbackAn EMS service which sends information about payment receipts to the online store
Card tokenA bankcard token, which is returned via callback, when the savecard parameter is sent in the request to create payment page - get /paymentpage. Later a said card token can be used for recurrent payments
Create invoiceMethod of creating an invoice, whereby the payment page opens without the online store’s participation. All invoice details are provided in advance by the merchant
CustomisationManual adjustment of the payment page elements in accordance with the online store design
EMSEMS, or ePayments Merchant Services Limited, is the organization providing merchant services
IframeMethod of creating an invoice whereby the payment page opens at the online store
InvoicePayment invoice provided to the buyer. Contains the payment amount, currency, and information about the payment recipient
MerchantA client using the merchant service for receiving online payments for goods and services on his/her website
Merchant serviceService for receiving online payments for goods or services
Online storeThe merchant’s website, which is integrated with the EMS API to receive payments
Payment methodPayment method of the goods or services in the online store. Selection of the payment method is carried out by the online store buyer in the payment page or via an API request in line with the terms of agreement between the merchant and EMS
Payment pageWeb page on which the buyer confirms payment in the online store by using one of the methods provided
Pre-authorisationTemporary blocking funds on a client’s card in order to debit them later
RedirectMethod of creating an invoice whereby the payment page opens at EMS. Redirection is carried out after clicking on the payment button in the online store
Recurrent paymentA recurrent payment, which is made using previously, saved bankcard. Initiated on the merchant side without the buyer

Test shop

To test the capabilities of the EMS service, a merchant is given access to a test web form. You can work with the form even without having a registered online shop in EMS.

Using this form a merchant can set parameters required to generate their payment page.

Web form can be accessed via the following link:

https://sb-ms.epayments.com/create-invoice

After opening the test form, the following fields are available to the merchant:

FieldDescription
Shop IDOnline shop identifier. Default value = 1
Shop SecretOnline shop secret key. Default value = secret
Order NumberOrder number, which is unique for this online shop. The value is generated automatically
Order NameOrder/product name
Order DescriptionShort description of the order
Order AmountThe amount, which will be paid for the order. Decimal separator – dot. No more than 2 characters can be entered after the dot
Payment CurrencyCurrency, which will be used to pay for the order. Currency type is selected from the list:
- USD (default),
- EUR,
- RUB
Gateway IDInvoice payment method:
- None;
- 1 – pay with card (default);
- 2 – pay via ePayments;
- 3 – pay via WebMoney
Payment Page LanguagePayment page language. Language is selected from the list:
- EN (default),
- ES,
- RU
Integration TypeInvoice creation method. Creation method is selected from the list:
- Redirect (default);
- Invoicing;
- Iframe
Payer e-mailPayer’s email. Can be field out only if the Integration type = Invoicing

Note
While working with the test web form it is recommended to use automatically generated data of the test online shop. Using personalized shop_id and shop_secret could result in some currencies and invoicing methods being unavailable.

After entering the test data, a merchant must press the Proceed button in order to generate the link to the payment page. After pressing the button the following button will become available (depending on the Integration type):

  • Copy Link – copy the link to the payment page;
  • Reload page – update data in the web form;
  • Go to Payment Page – go to the payment page.

Test details

To test payments with bankcard the merchant may use the following test details:

Test bank card3D SecureTransfer status
Number: 5413330000000019
Expiry date: 01/20
CVC: 589
Card supports 3D SecureSuccessful
Number: 4314220000000049
Expiry date: 01/22
CVC: 589
Card does not support 3D SecureSuccessful
Number: 5142905574265797
Expiry date: 01/20
CVC: 221
Card does not support 3D SecureDeclined by bank
Number: 2200774546102058
Expiry date: 04/21
CVC: 986
Card does not support 3D SecureDeclined by transfer provider
Note
When working with test bankcards with 3D-secure support, you must enter the correct password in the "SecureCode" field to confirm the operation. Otherwise, the test card will be blocked.

To test payments with ePayments e-Wallet, you can contact your account manager directly or submit a request using the ticket system in your ePayments personal account. Test ePayments account details will be sent to you after it.


To test payments with payment with WebMoney wallet, you can use your own WebMoney wallet. Funds will not be written off from your wallet, since test account will be used as a transfer recipient.

Error codes

Error codeDescription
1001002Error in one or several parameters
1001006Access denied
1001007The domain of the address provided must be the same as the main domain
2001002Error in shop settings
2001003Error in shop settings
2001004Error in shop settings
2001005Error in shop settings
2001006Error in shop settings
2001008Error in shop settings
2001009Error in shop settings
2001010Error in shop settings
2001011Error in shop settings
2001012The store has an incorrect tariff position for the payment method
2001014The store does not have a tariff position
2001016Redirect page address missing
2001018Recurrent payment is prohibited by the shop settings
2002000Unknown error related to incoming payment
2002001Incoming payment not found
2002002The incoming payment has not been found for the operation identifier
2002004Incorrect format
2002005Value must be positive
2002006The order number provided already exists
2002007Error when creating an object
2002011Incoming payment for order number has not been found
2002013The incoming payment does not have a transaction identifier on the side of the payment method
2002015OperationLifetime not provided or store has incorrect settings
2002016Invoice expired
2002017Operation cancelled
2002019The value of the specified currency should not have CcyMnrUnts = N. A.
2002020The number of characters after the point does not match the currency standard
2002024Payment cannot be repeated
2002025The original operation with the specified card token does not exist
2003000Unknown error related to payment processing
2005000Unknown error related to payment systems
2005002Payment system does not exist
2005003Error in payment system settings
2005004Error in payment system settings
2005005Unsupported payment system type
2006000Unknown error related to limits
2006001Value exceeds the one-time limit
2006002Value exceeds the cumulative limit
2006003Limit position provided incorrectly
2007000Unknown error related to e-Wallets
2007001e-Wallet not found
2008001Incorrect operation status
2008002Operation with the provided identifier does not exist
2008003Action is not allowed for this operation type
2008005Refund for the operation has already been carried out
2008006Incorrect number of transactions for the operation
2009000Unknown error related to currencies
2009001The currency does not exist
2009002The currency with this Id does not exist
2010000Unknown error related to the payment page
2011001No exchange rate found for the selected currency
2011002Currency exchange rate has expired
2011003No worsening conversion rate was found for a currency pair
2013001Refund amount does not match the incoming payment amount
2013002Incoming transaction is not found
2014000Unknown error related to tariffs
2017000Unknown error related to the account details of the payment method
2017001Account details for the payment method do not exist
2017002Account details of the payment method are of an incorrect format
9000000Error on the side of the payment system
9000001Payment system timed out

History of changes

History of changes

v1.12 (2019-06-11)

  • A new payment scenario - Direct was added. It is used to bill saved bankcards.
  • A new payment method - via Yandex.Money wallet was added.
  • A new parameter - cardHolderName was added to the GET /paymentpage method. It is used to generate a payment page without cardholder name field.
  • A few changes were made in the EMS payment form design. A button to clear the field was added, the method to switch languages has been changed, several buttons have been renamed.

v1.11 (2019-04-30)

  • A new method - One click payment for working with payments made via saved bankcards was added.
  • URLs required to access EMS staging environment were updated.

v1.10 (2019-04-22)

  • Requirements for displaying the “Email” field on the payments page were changed.
  • A new parameter - TimeToReject was added. This parameter can be transferred during online shop registration.
  • The WalletIdentifier parameter with buyer wallet number was added to the payment status callback. Said parameter is transmitted is invoice is paid via WebMoney wallet or ePayments e-Wallet
  • New non-mandatory parameters – AutoReturn for automatic redirecting and MerchRefCode for payer identification, were added to the get /paymentpage method.
  • A display of website without protocol (http://www) was added to the email notification.

v1.9 (2019-03-25)

v1.8 (2019-02-06)

  • A new method for working with bankcard payments - recurrent payments was added.
  • A new method of accepting payments - from WebMoney wallet - was added.
  • New parameters for accepting payments - MaxRebillAttempts, UsedRebillAttempts, InvoiceExpDateTime have been added to the Callback.
  • A list of fields that are displayed in email notifications upon receipt of the payment result was updated.
  • A feature allowing to save the buyer’s card via the saveCard parameter when successfully accepting a payment was added. It is available to merchants with the corresponding store settings.