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:

• 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.

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.

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:

Not-Mandatory Callback parameters:

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

• Creating link to pay for the invoice - GET /paymentpage.
• Refunding an invoice if payment was made via bankcard - POST /card/refund.
• Cancelling created invoices - POST /cancel.
• Creating recurrent payments - POST /recurrent.
• Receiving operations’ callbacks.

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

• Personalization and customization of payment form (customization).
• Creating link to pay for the invoice - GET /paymentpage.
• Refunding an invoice if payment was made via bankcard - POST /card/refund.
• Cancelling created invoices - POST /cancel.
• Creating recurrent payments - POST /recurrent.
• Receiving operations’ callbacks.

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.

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);
}

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;
}

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

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:

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;
}

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:

• Creating link to pay for the invoice - GET /paymentpage.
• Refunding an invoice if payment was made via bankcard - POST /card/refund.
• Cancelling created invoices - POST /cancel.
• Creating recurrent payments - POST /recurrent.
• Rebilling an invoice - POST /rebill
• Receiving operations’ callbacks.

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.

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.

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

• Creating payment - POST /v1/payment.
• Refund - POST /card/refund.
• Cancelling created invoices - POST /cancel.
• Charging bankcard - POST /card/charge.
• Refunding an invoice if payment was made via bankcard - POST /card/cancel.
• Creating a recurrent payment - POST /recurrent.
• Receiving operations’ callbacks.

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.

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.

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)

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

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.

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

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.

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.

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.

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%.

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.

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.

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

Mandatory callback parameters:

Not-Mandatory Callback parameters:

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

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:

Non-mandatory callback parameters:

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

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:

Not-Mandatory Callback parameters:

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

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.

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:

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.

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

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.

• 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.

• 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.

• 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.

• A new method for accepting payments - pre-authorisation, was added.

• 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.