Description of interaction patterns

One-phase payments

Order payment scenario (1)


One-phase card payment pattern:

  • 1. The client places an order on the merchant's resource and chooses a method of payment by bank card.
  • 2. After the bank card payment method is selected, a request for order registration must be sent to the payment gateway. For registration, parameters such as the debit amount, the order number in the store's system, as well as the client's return URL are used. The request specification is presented in the following sections:
  • Request for order registration (WS),
  • Request for order registration (REST).
  • 3. In response to the registration request, the payment gateway returns a unique order identifier in the payment system (in the orderId parameter) and the URL to which the user must be redirected to receive the payment form (in the formUrlparameter).
  • 4. The Store's system must redirect the Client's browser to the URL received from the payment gateway in the formUrl parameter in response to the order registration request. .
  • 5. The client's browser opens the received URL.
  • 6. The Client receives the payment form.
  • 7. The user fills in the received form with the card details and sends the data to the payment gateway server.
  • 8. The order details are transmitted to the fraud control system to determine the fraud probability. Verification is carried out using a set of automatic rules. The result of applying the rule is the addition of a fraud probability factor (fraud score) to the order. Each rule has its own fraud score, which is a number in the range from 0 to 100. (If the total fraud score of the order for all rules applied to the order exceeds 100, such an order is considered fraudulent and payment for it will be rejected.)
  • 9.

    The results of checking the order for fraud are returned to the payment gateway.
    In the event that, according to the store's settings, the payment must go over SSL, then the next step of the scenario (10) is performed.
    If, according to the store's settings, the payment must be 3DS, the following actions will be performed

    • The payment gateway checks the card's enrolment in 3-D Secure.
      If authorization through ACS is not required for this card, then the next step of the scenario (10) is executed.
      If authorization through ACS is required, the following actions will be performed:

      • 1. The gateway redirects the client's browser to the ACS page of the issuing bank.
      • 2. The client's browser requests a user authorization form from ACS (each issuer does this in its own way)
      • 3. ACS sends an authorization form to the client's browser.
      • 4. The client fills out the authorization form and sends it to ACS.
      • 5. ACS processes the completed form and, regardless of the result, sends to the browser the redirect to the payment gateway page URL. The encrypted parameters of the authorization result are transmitted along with this URL.
      • 6. The client's browser requests the payment gateway page, transmitting encrypted parameters of the authorization result. If authorization was successful, the next step of the scenario is executed.
  • 10. The payment gateway makes the payment (debiting funds from the client's account)
  • 11. After the payment, the payment gateway transmits to the client's browser the URL of the return to the store's page (previously specified by the store when registering the order, see step 2).
  • 12. The client's browser requests a page with the payment results from the store.
  • 13.

    The store's system requests the order payment status from the payment gateway (by the unique order ID in the payment system, which was received when the order was registered in the orderId parameter).
    The specification of the normal order status request is presented in the following sections:

  • Order status request (WS),

  • Order status request (REST).
    The specification of the advanced order status request is presented in the following sections:

  • Advanced order status request (WS),
  • Advanced order status request (REST).
  • 14. The payment gateway returns the payment status.
  • 15. The store's system sends to the client's browser a page with the payment results – a successful payment or an unsuccessful one..

Cancellation of order payment (1)

Cancellation of order payment is available to stores if they have the appropriate rights (in agreement with the bank). For one-phase payments, payment cancellation is possible for orders in the Completed/Deposited state.
Order payment is cancelled by standard means:

If the cancellation operation is successful, the order will be transferred from the Completed/Deposited state to the Canceled/Reversed state..

Refund of order payment funds (1)

A full or partial refund for paid orders (in the Completed/Deposited state) is carried out by standard means:

After IPS receives a refund request sent by one of the above methods, IPS returns the specified amount to the client's account.

Verification of the card's enrolment in 3DS (1)

The system allows the store to independently verify the enrolment of the bank card in 3-D Secure, if necessary. This can be done using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Adding additional parameters to the order (1)

The system allows you to add additional parameters to the order if necessary. This can be done using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Statistics on payments for a certain period (1)

The system allows you to generate statistics on payments for a certain period using the API, through SOAP / REST interfaces. The request specification is presented in the following sections:

Two-phase payments

Order payment scenario (2)


Two-phase card payment pattern:

  • 1. The client places an order on the merchant's resource and chooses a method of payment by bank card.
  • 2. After the bank card payment method is selected, a request for order registration with pre-authorization must be sent to the payment gateway. For registration, parameters such as the debit amount, the order number in the store's system, as well as the client's return URL are used. The request specification is presented in the following sections:
  • Request for order registration with pre-authorization (WS) ,
  • Request for order registration with pre-authorization (REST) .
  • 3. In response to the registration request, the payment gateway returns a unique order identifier in the payment system (in the orderId parameter) and the URL to which the user must be redirected to receive the payment form (in the formUrl parameter).
  • 4. The Store's system must redirect the Client's browser to the URL received from the payment gateway in the formUrl parameter in response to the order registration request.
  • 5. The client's browser opens the received URL.
  • 6. The Client receives the payment form.
  • 7. The user fills in the received form with the card details and sends the data to the payment gateway server.
  • 8. The order details are transmitted to the fraud control system to determine the fraud probability. Verification is carried out using a set of automatic rules. The result of applying the rule is the addition of a fraud probability factor (fraud score) to the order. Each rule has its own fraud score, which is a number in the range from 0 to 100. (If the total fraud score of the order for all rules applied to the order exceeds 100, such an order is considered fraudulent and payment for it will be rejected.)
  • 9.

    The results of checking the order for fraud are returned to the payment gateway.
    In the event that, according to the store's settings, the payment must go over SSL, then the next step of the scenario (10) is performed.
    If, according to the store's settings, the payment must be 3DS, the following actions will be performed:

    • The payment gateway checks the card number to determine whether the use of 3-D Secure technology is required when making a payment.
      If authorization through ACS is not required for this card, then the next step of the scenario (10) is executed.
      If authorization through ACS is required, the following actions will be performed:

      • 1. The gateway redirects the client's browser to the ACS page of the issuing bank.
      • 2. The client's browser requests a user authorization form from ACS (each issuer does this in its own way)
      • 3. ACS sends an authorization form to the client's browser.
      • 4. The client fills out the form and sends it to ACS.
      • 5. ACS processes the completed form and, regardless of the result, sends to the browser the redirect to the payment gateway page URL. The encrypted parameters of the authorization result are transmitted along with this URL.
      • 6. The client's browser requests the payment gateway page, transmitting encrypted parameters of the authorization result. If authorization was successful, the next step of the scenario is executed.
  • 10. The payment gateway authorizes the payment (holding funds on the client's card account).
  • 11. After the payment, the payment gateway transmits to the client's browser the URL of the return to the store's page (previously specified by the store when registering the order, see step 2).
  • 12. The client's browser requests a page with the payment results from the store.
  • 13.

    The store's system requests the order payment status from the payment gateway (by the unique order ID in the payment system, which was received when the order was registered in the orderId parameter).
    The specification of the normal order status request is presented in the following sections:

  • Order status request (WS),

  • Order status request (REST).
    The specification of the advanced order status request is presented in the following sections:

  • Advanced order status request (WS),
  • Advanced order status request (REST).
  • 14. The payment gateway returns the payment status.
  • 15. The store's system sends to the client's browser a page with the payment results – a successful payment or an unsuccessful one..
  • 16. To debit funds from the client's account, the store must send a request for order payment completion to the payment gateway. The request specification is presented in the following sections:
  • Request for order payment completion (WS),
  • Request for order payment completion (REST).
  • 17. The payment gateway returns the result of processing the request. The order status is not refundable. To receive an order, one must send a corresponding request to the gateway, as described in step 13.

Cancellation of order payment (2)

Cancellation of order payment is available to stores if they have the appropriate rights (in agreement with the bank). For two-phase payments, payment can be canceled for an order in the Confirmed/Approved state.
Order payment is cancelled by standard means:

If the cancellation operation is successful, the order will be transferred from the Confirmed/Approved state to the Canceled/Reversed state.

Refund of order payment funds (2)

A full or partial refund for paid orders (in the Completed/Deposited state) is carried out by standard means:

After IPS receives a refund request sent by one of the above methods, IPS returns the specified amount to the client's account.
(2)

Verification of the card's enrolment in 3DS (2)

The system allows the store to independently verify the enrolment of the bank card in 3-D Secure, if necessary. This can be done using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Adding additional parameters to the order (2)

The system allows you to add additional parameters to the order if necessary. This can be done using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Statistics on payments for a certain period (2)

(2)
The system allows you to generate statistics on payments for a certain period using the API, through SOAP / REST interfaces. The request specification is presented in the following sections:

One-phase autopayments

Initial payment scenario (1)


  • 1. The client places an order on the store's resource and chooses a method of payment by bank card.
  • 2. After the bank card payment method is selected, a request for order registration must be sent to the payment gateway with the mandatory transmission of the unique client ID in the clientId parameter. For registration, parameters such as the debit amount, the order number in the store's system, and the client's return URL are also used. The request specification is presented in the following sections:
  • Request for order registration (WS),
  • Request for order registration (REST).
  • 3. In response to the registration request, the payment gateway returns a unique order identifier in the payment system (in the orderId parameter) and the URL to which the user must be redirected to receive the payment form (in the formUrl response parameter).
  • 4. The Store's system must redirect the Client's browser to the URL received from the payment gateway in the formUrl parameter in response to the order registration request.
  • 5. The client's browser opens the received URL.
  • 6. The Client receives the payment form.
  • 7. The client fills in the received form with the card details and sends the data to the payment gateway server.
  • 8. The order details are transmitted to the fraud control system to determine the fraud probability. Verification is carried out using a set of automatic rules. The result of applying the rule is the addition of a fraud probability factor (fraud score) to the order. Each rule has its own fraud score, which is a number in the range from 0 to 100. (If the total fraud score of the order for all rules applied to the order exceeds 100, such an order is considered fraudulent and payment for it will be rejected.)
  • 9. The results of checking the order for fraud are returned to the payment gateway.
  • 10.

    The payment gateway checks the card's enrolment in 3-D Secure.
    If authorization through ACS is not required, then the next step of the scenario (11) is executed.
    If authorization through ACS is required, the following actions will be performed:

    • 1. The gateway redirects the client's browser to the ACS page of the issuing bank.
    • 2. The client's browser requests a user authorization form from ACS (each issuer does this in its own way).
    • 3. ACS sends an authorization form to the client's browser.
    • 4. The client fills out the authorization form and sends it to ACS.
    • 5. ACS processes the completed form and, regardless of the result, sends to the browser the redirect to the payment gateway page URL. The encrypted parameters of the authorization result are transmitted along with this URL.
    • 6. The client's browser requests the payment gateway page, transmitting encrypted parameters of the authorization result. If authorization was successful, the next step of the scenario is executed.
  • 11. The payment gateway makes the payment (debiting funds from the client's account).
  • 12. In case of successful payment, a binding will be created in the payment gateway (the card data that was used for payment is linked to the client ID transferred in step 2 in the clientId parameter).
  • 13. After the payment is made, the payment gateway transmits to the client's browser the URL of the return to the store's page (previously specified by the store when registering the order, see step 2).
  • 14. The client's browser requests a page with the payment results from the store.
  • 15.

    The store's system requests the order status from the payment gateway (by the unique order identifier in the payment system, which was received in step 3 in the orderId parameter).
    The specification of the normal order status request is presented in the following sections:

  • Order status request (WS),

  • Order status request (REST).
    The specification of the advanced order status request is presented in the following sections:

  • Advanced order status request (WS),
  • Advanced order status request (REST).
  • 16. The payment gateway returns the order payment status (in the orderStatus parameter), as well as the unique identifier of the binding (in the bindingId parameter).
  • 17.

    The store's system sends to the client's browser a page with the payment results – a successful payment or an unsuccessful one.
    After successful initial payment the store enables the Autopayment service to the client (determines the date and amount of the debit for this client). In the future, the store independently tracks the date when it is necessary to make the next autopayment, and initiates payment by the binding ID.

Autopayment scenario (1)

When the date of the next autopayment comes, the store initiates the payment according to the following scenario:

  • 1. A request for order registration must be sent to the payment gateway with the mandatory transmission of the unique client identifier in the clientId parameter. For registration, parameters such as the debit amount, the order number in the store's system, and the client's return URL are also used. The request specification is presented in the following sections:
  • Request for order registration (WS),
  • Request for order registration (REST).
  • 2. In response to the registration request, the payment gateway returns a unique order identifier in the payment system (in the orderId parameter).
  • 3. The store sends a request for order payment using a binding, transmitting the order number in the payment system received at the previous step and the binding ID received after the initial payment. The request specification is presented in the following sections:
  • Request to make a binding payment (WS),
  • Request to make a binding payment (REST).
  • 4. The payment gateway makes the payment (debiting funds from the client's account).
  • 5.

    The store's system requests the order status from the payment gateway (by the unique order identifier in the payment system, which was received in step 2 in the orderId parameter).
    The specification of the normal order status request is presented in the following sections:

  • Order status request (WS),

  • Order status request (REST).
    The specification of the advanced order status request is presented in the following sections:

  • Advanced order status request (WS),
  • Advanced order status request (REST).
  • 6. The payment gateway returns the payment status (in the orderStatus parameter).

Getting a list of client bindings (1)

The store can get a list of IDs of existing bindings for a specific clientId by sending a corresponding request to the payment gateway. The request specification is presented in the following sections:

Deactivation/activation of an existing binding (1)

The system allows stores, if necessary, to deactivate existing bindings using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Changing the validity period of a binding (1)

A change in the validity period of a binding may be required in case of reissue of the client's card. This can be done using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Two-phase autopayments

Initial payment scenario (2)


  • 1. The client places an order on the merchant's resource and chooses a method of payment by bank card.
  • 2. After the bank card payment method is selected, a request for order pre-registration must be sent to the payment gateway with the mandatory transmission of the unique client ID in the clientId parameter. For registration, parameters such as the debit amount, the order number in the store's system, and the client's return URL are also used. The request specification is presented in the following sections:
  • Request for order registration with pre-authorization (WS) ,
  • Request for order registration with pre-authorization (REST) .
  • 3. In response to the registration request, the payment gateway returns a unique order identifier in the payment system (in the orderId parameter) and the URL to which the user must be redirected to receive the payment form (in the formUrl response parameter).
  • 4. The Store's system must redirect the Client's browser to the URL received from the payment gateway in the formUrl parameter in response to the order registration request.
  • 5. The client's browser opens the received URL
  • 6. The Client receives the payment form.
  • 7. The client fills in the received form with the card details and sends the data to the payment gateway server.
  • 8. The order details are transmitted to the fraud control system to determine the fraud probability. Verification is carried out using a set of automatic rules. The result of applying the rule is the addition of a fraud probability factor (fraud score) to the order. Each rule has its own fraud score, which is a number in the range from 0 to 100. (If the total fraud score of the order for all rules applied to the order exceeds 100, such an order is considered fraudulent and payment for it will be rejected.)
  • 9. The results of checking the order for fraud are returned to the payment gateway.
  • 10.

    After receiving the payment details, the payment gateway checks the card's enrolment in 3-D Secure.
    If authorization through ACS is not required, then the next step of the scenario (11) is executed.
    If authorization through ACS is required, the following actions will be performed:

    • 1. The gateway redirects the client's browser to the ACS page of the issuing bank.
    • 2. The client's browser requests a user authorization form from ACS (each issuer does this in its own way).
    • 3. ACS sends an authorization form to the client's browser.
    • 4. The client fills out the authorization form and sends it to ACS.
    • 5. ACS processes the completed form and, regardless of the result, sends to the browser the redirect to the payment gateway page URL. The encrypted parameters of the authorization result are transmitted along with this URL.
    • 6. The client's browser requests the payment gateway page, transmitting encrypted parameters of the authorization result. If authorization was successful, the next step of the scenario is executed.
  • 11. The payment gateway makes the payment (holding funds on the client's card account).
  • 12. In case of successful holding of the amount on the card, a binding will be created in the payment gateway (the card data that was used for payment is linked to the client ID transferred in step 2 in the clientId parameter).
  • 13. After the payment is made, the payment gateway transmits to the client's browser the URL of the return to the store's page (previously specified by the store when registering the order, see step 2).
  • 14. The client's browser requests a page with the payment results from the store.
  • 15.

    The store's system requests the order status from the payment gateway (by the unique order identifier in the payment system, which was received in step 3 in the orderId parameter).
    The specification of the normal order status request is presented in the following sections:

  • Order status request (WS),

  • Order status request (REST).
    The specification of the advanced order status request is presented in the following sections:

  • Advanced order status request (WS),
  • Advanced order status request (REST).
  • 16. The payment gateway returns the order payment status (in the orderStatus parameter), as well as the unique identifier of the binding (in the bindingId parameter).
  • 17. The store's system sends to the client's browser a page with the payment results – a successful payment or an unsuccessful one.
  • 18. To debit the reserved funds from the client's account, the store must send a request for order payment completion to the payment gateway. The request specification is presented in the following sections:
  • Request for order payment completion (WS),
  • Request for order payment completion (REST).
  • 19.

    The payment gateway returns the result of processing the request. The order status is not refundable. To receive an order, one must send a corresponding request to the gateway, as described in step 15.
    After successful initial payment the store enables the Autopayment service to the client (determines the date and amount of the debit for this client). In the future, the store independently tracks the date when it is necessary to make the next autopayment, and initiates payment by the binding ID.

Autopayment scenario (2)

When the date of the next autopayment comes, the store initiates the payment according to the following scenario:

  • 1. A request for order pre-registration must be sent to the payment gateway with the mandatory transmission of the unique client identifier in the clientId parameter. For registration, parameters such as the debit amount, the order number in the store's system, and the client's return URL are also used. The request specification is presented in the following sections:
  • Request for order registration with pre-authorization (WS) ,
  • Request for order registration with pre-authorization (REST) .
  • 2. In response to the registration request, the payment gateway returns a unique order identifier in the payment system (in the orderId parameter).
  • 3. The store sends a request for order payment using a binding, transmitting the order number in the payment system received at the previous step and the binding ID received after the initial payment. The request specification is presented in the following sections:
  • Request to make a binding payment (WS),
  • Request to make a binding payment (REST).
  • 4.

    The payment gateway makes a payment (holding funds on the client's card account) and returns the result of processing the request. The order status is not refundable. To receive an order, one must send a corresponding request to the gateway.
    The specification of the normal order status request is presented in the following sections:

  • Order status request (WS),

  • Order status request (REST).
    The specification of the advanced order status request is presented in the following sections:

  • Advanced order status request (WS),
  • Advanced order status request (REST).
  • 5. The payment gateway returns the order status (in the orderStatus parameter).
  • 6. To debit funds from the client's account, the store must send a request for order payment completion to the payment gateway. The request specification is presented in the following sections:
  • Request for order payment completion (WS),
  • Request for order payment completion (REST).
  • 7. The payment gateway returns the result of processing the request. The order status is not refundable. To receive an order, one must send a corresponding request to the gateway, as described in step 4.

Getting a list of client bindings (2)

The store can get a list of IDs of existing bindings for a specific clientId by sending a corresponding request to the payment gateway. The request specification is presented in the following sections:

Deactivation/activation of an existing binding (2)

The system allows stores, if necessary, to deactivate existing bindings using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Changing the validity period of a binding (2)

A change in the validity period of a binding may be required in case of reissue of the client's card. This can be done using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Payment using a binding on the payment page

General description of the functionality and addition on the payment page

This functionality is used to link the card number to the buyer's ID in the store's system (for example, to the login).
If, after authorization on the store's website and successful payment of the order by card, the client re-places an order on this website under the same id, then when redirected to the payment page, they will be prompted to autofill all card data, excluding CVC/CVV.
If the merchant is supposed to use the functionality of bindings, the payment page may contain a form for selecting a binding to pay for the order. The form design must meet the following conditions:

  • The form shall have an identifier id="formBinding".
  • The form shall be hidden by default using the "display: none;" CSS property.
  • The form shall contain a drop-down list for selecting a binding with the name="bindingId" name.
  • The drop-down list shall contain one choice: <option value="" selected="selected">other</option>, when selected the user makes a regular payment by card, without using the functionality of bindings.
  • The form must contain a CVC/CVV input field with the name="cvc" name.
  • The form must contain a "Pay" button: <input value="Pay" type="button" id="buttonBindingPayment"> with the id="buttonBindingPayment" identifier.
  • The CVC/CVV input field and the Pay button should be framed with elements with the class="rbs_hidden" class. When choosing a payment option without using the bindings functionality, these elements will be hidden by setting the "display: none;" CSS property.

Form example:

html 
        <form action="" id="formBinding" style="display: none;">
    <table cellpadding="10">
        <tbody>
        <tr valign="TOP">
            <td valign="top" width="50%" align="right">
                <span>Select a card:</span>
            </td>
            <td valign="top">
                <select name="bindingId">
                    <option value="" selected="selected">other</option>
                </select>
            </td>
        </tr>
        <tr class="rbs_hidden">
            <td align="right">
                <span>Enter CVC2/CVV2/CID code  :</span><br>(located on the back of the card)
            </td>
            <td>
                <input name="cvc" maxlength="4" type="password" autocomplete="off"/>
            </td>
        </tr>
        <tr class="rbs_hidden">
            <td></td>
            <td valign="top">
                <input value="Pay" type="button" id="buttonBindingPayment">
            </td>
        </tr>
        </tbody>
    </table>
</form>

Order payment scenario


  • 1. The client places an order on the merchant's resource and chooses a method of payment by bank card.
  • 2. After the bank card payment method is selected, a request for order registration must be sent to the payment gateway with the mandatory transmission of the unique client ID in the clientId parameter. For registration, parameters such as the debit amount, the order number in the store's system, and the client's return URL are also used. The request specification is presented in the following sections:
  • Request for order registration (WS),
  • Request for order registration (REST).
  • 3. In response to the registration request, the payment gateway returns a unique order identifier in the payment system (in the orderId parameter) and the URL to which the user must be redirected to receive the payment form (in the formUrl response parameter).
  • 4. The Store's system must redirect the Client's browser to the URL received from the payment gateway in the formUrl parameter in response to the order registration request.
  • 5. The client's browser opens the received URL.
  • 6. The Client receives the payment form.
  • 7.

    If a binding has not yet been created for this clientId, the client fills in the received form with the card details and checks the "Remember the data of this card" box. The client then sends the data to the payment gateway server.
    If one or more linked cards exist for this clientId, they are displayed in the drop-down list in the PAN input field. The client selects the desired card (it is also possible to enter the details of a new card). The client then sends the data to the payment gateway server.

  • 8. The order details are transmitted to the fraud control system to determine the fraud probability. Verification is carried out using a set of automatic rules. The result of applying the rule is the addition of a fraud probability factor (fraud score) to the order. Each rule has its own fraud score, which is a number in the range from 0 to 100. (If the total fraud score of the order for all rules applied to the order exceeds 100, such an order is considered fraudulent and payment for it will be rejected.)
  • 9.

    The results of checking the order for fraud are returned to the payment gateway.
    If the store's settings require a SSL payment, then the next step of the scenario (10) is executed.
    If, according to the store's settings, the payment must be 3DS, the following actions will be performed:

    • 1.

      After receiving the payment details, the payment gateway checks the card number to determine whether the use of 3-D Secure technology is required when making a payment.
      If the use of 3DS technology is not required, then the next step of the scenario (10) is executed.
      If the payment must be 3DS, then the following actions will be performed:

      • 1. The gateway redirects the client's browser to the ACS page of the issuing bank.
      • 2. The client's browser requests a user authorization form from ACS (each issuer does this in its own way)
      • 3. ACS sends an authorization form to the client's browser.
      • 4. The client fills out the authorization and sends it to ACS.
      • 5. ACS processes the completed form and, regardless of the result, sends to the browser the redirect to the payment gateway page URL. The encrypted parameters of the authorization result are transmitted along with this URL.
      • 6. The client's browser requests the payment gateway page, transmitting encrypted parameters of the authorization result. If authorization was successful, the next step of the scenario is executed.
  • 10. The payment gateway makes the payment (debiting funds from the client's account)
  • 11. After the payment is made, the payment gateway transmits to the client's browser the URL of the return to the store's page (previously specified by the store when registering the order, see step 2).
  • 12. The client's browser requests a page with the payment results from the store.
  • 13. The store's system requests the order payment status from the payment gateway (by the unique order ID in the payment system, which was received when the order was registered in the orderId parameter). The specification of the normal order status request is presented in the following sections:
  • Order status request (WS),

  • Order status request (REST).
    The specification of the advanced order status request is presented in the following sections:

  • Advanced order status request (WS),
  • Advanced order status request (REST).
  • 14. The payment gateway returns the payment status.
  • 15. The store's system sends to the client's browser a page with the payment results – a successful payment or an unsuccessful one.

Getting a list of client bindings

If at Step 5 of the scenario, the client entered the details of a new card on the payment page and ticked "Remember the details of this card", then in case of successful payment, a unique binding identifier will be created on the payment gateway side. The store can get a list of IDs of existing bindings for a specific clientId by sending a corresponding request to the payment gateway. The request specification is presented in the following sections:

Getting a list of bank card bindings

If the appropriate permissions are available, the store can request a list of all bindings related to a particular bank card. One can do this by card number or by a known binding identifier. The request specification is presented in the following sections:

Deactivating/activating of an existing binding

The system allows stores, if necessary, to deactivate existing bindings using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Changing the validity period of a binding

A change in the validity period of a binding may be required in case of reissue of the client's card. This can be done using the API, via SOAP/REST interfaces. The request specification is presented in the following sections:

Using Alfa-Click to pay for an order

Brief description of the PayByClick system

The PayByClick system is another payment means of the payment gateway along with payment by bank cards. At the same time, the pattern of interaction between the online store and the payment gateway does not change.
Payment via PayByClick is intended for clients of Alfa-Click online banking.
The integration pattern depends on the method of using the Alfa-Click payment method:

  • 1. The seller accepts payments via Alfa-Click along with the use of e-commerce. In this case, the button to switch to the PayByClick system is located on the payment page, where the client is redirected to pay for the order. A description of the payment process is provided in the "Using Alfa-Click and e-commerce" section.
  • 2.

    The seller accepts payments only through Alfa-Click. In this case, a payment request via Alfa-Click is created to redirect the client to the PayByClick system. A description of the payment process is provided in the "Using Alfa-Click only" section.
    The PayByClick system does not provide for the possibility of partial debit of a pre-authorized order (with a two-phase process), partial payment, partial or full refund (reversal or refund). Payment is possible only in rubles. There is no possibility of placing the data entry page for payment on the side of the store's website.
    The existing registers of e-invoicing payments are used for reconciliation.

Scenarios for order payment via Alfa-Click

Using Alfa-Click and e-commerce

If the store uses Alfa-Click along with e-commerce, then when creating a payment page, in addition to the standard requirements described in the "Payment page layout" document, a requirement is added to place a button element on the page:
<input type="button" class="alfaclick" id="buttonPaymentAlfa" value="Pay via Alpha Click" />"
It is also possible to upload a standard payment page to the store, where a button is already placed to proceed to payment via Alpha-Click.

  • 1. The client generates an order on the store's website.
  • 2. After the client confirms the order, the store registers the order in IPS. For registration, parameters such as the debit amount, the order number in the store's system, as well as the client's return URL are used. The request specification is presented in the following sections:
  • Request for order registration (WS),
  • Request for order registration (REST).
  • 3. IPS returns the order ID and the URL of redirecting the client to the payment form. If the payment method selection is implemented on the payment page side, steps 4-6 are performed. If payment is selected on the store's side, the URL is transferred at this step to continue at step 7.
  • 4. The store sends the redirect to the URL received in step 3 to the client.
  • 5. The client opens the received URL by requesting a payment form.
  • 6. A form for selecting the type of payment is displayed to the client. When "Pay via Alpha-Click" is selected, the client is redirected to PayByClick.
  • 7.

    The client's browser requests a form of authorization with the transfer of parameters:

    • Order ID (received in step 3);
    • BackURL to return to the order status request page (transferred in the request for order registration in step 2).
  • 8. PayByClick requests order data by its ID.
  • 9. IPS returns the order data.
  • 10. Alfa-Click client authentication and Alfa-Click payment authorization operations.
  • 11. Alfa-Click client authentication and Alfa-Click payment authorization operations.
  • 12. Alfa-Click client authentication and Alfa-Click payment authorization operations.
  • 13. Alfa-Click client authentication and Alfa-Click payment authorization operations.
  • 14. PayByClick sends the client a redirect to the IPS URL received in step 7 and shuts down. In this case, the payment status is not transferred, only the order ID is transferred.
  • 15. The client's browser opens the received BackURL of the payment status request page.
  • 16. The payment status of the order is checked on the page.
  • 17. After the order status gets the required value (DEPOSITED), there is a redirect to the store page to display the payment status of the order.
  • 18. The user receives a page with the payment status.

Using Alfa-Click only

The main process of payment through the PayByClick system is described below (without negative scenarios) if the store accepts payment only through the PayByClick system:

  • 1. The client generates an order on the store's website.
  • 2. After the client confirms the order, the store registers the order in IPS. For registration, parameters such as the debit amount, the order number in the store's system, as well as the client's return URL are used. The request specification is presented in the following sections:
  • Request for order registration (WS),
  • Request for order registration (REST).
  • 3. IPS returns the order ID.
  • 4. The store sends a request for order payment to IPS via Alfa-Click, transferring the order ID received in step 3. To do this, an alternative payment request is used with the mandatory transfer of the ALFA_ALFACLICK value in the paymentWay parameter, as well as the order ID. The request specification is presented in the following sections:
  • Request for payment via an external payment system (WS),
  • Request for payment via an external payment system (REST).
  • 5. In response, the payment gateway sends a URL to redirect the client to the PayByClick system.
  • 6. The client's browser is redirected to the PayByClick system.
  • 7.

    The client's browser requests a form of authorization with the transfer of parameters:

    • Order ID (received in step 3);
    • BackURL to return to the order status request page (transferred in the request for order registration in step 2).
  • 8. PayByClick requests order data by its ID.
  • 9. IPS returns the order data.
  • 10. Alfa-Click client authentication and Alfa-Click payment authorization operations.
  • 11. Alfa-Click client authentication and Alfa-Click payment authorization operations.
  • 12. Alfa-Click client authentication and Alfa-Click payment authorization operations.
  • 13. Alfa-Click client authentication and Alfa-Click payment authorization operations.
  • 14. PayByClick sends the client a redirect to the IPS URL received in step 7 and shuts down. In this case, the payment status is not transferred, only the order ID is transferred.
  • 15. The client's browser opens the received BackURL of the payment status request page.
  • 16. The payment status of the order is checked on the page.
  • 17. After the order status gets the required value (DEPOSITED), there is a redirect to the store page to display the payment status of the order.
  • 18. The user receives a page with the payment status.

Testing of payment via Alfa-Click

  • 1. Register the order in the payment gateway. Order registration can be carried out using REST/ SOAP.
  • 2.

    The transition to the PayByClick system is carried out:

    • After clicking the "You can pay via Alfa-Click" button on the payment page, if the client was redirected to it after registering the order,
    • After sending a request for payment via Alfa-Click (REST/SOAP).
  • 3.

    The page for payment via Alfa-Click will open at http://217.12.96.193/PayByClick/login.xhtml?faces-redirect=true:

  • 4.

    Enter the Alpha-Click login and password, and then click "Continue". Test details:

    • Alfa-Click login: 6819507
    • Alfa-Click password: 000000
  • 5.

    The "Authorization" page opens:

  • 6. Enter a one-time password and click "Continue". Test one-time password: 0000.
  • 7.

    The page for selecting the debit account opens:

  • 8. Select the debit account from the drop-down list and click the "Pay" button. You will be redirected to the store page specified during order registration.
  • 9. After that, the payment is considered formally completed. Upon returning to the store's website after payment, the payment status is not transferred in the Alfa-Click system. Therefore, in order to clarify the payment status, the store needs to poll the IPS system through a standard order status request (getOrderStatus) and wait for the order to go to the DEPOSITED state (funds are debited).

Using UPOP to pay for an order

Brief description of the CUP system

The UPOP tool is a payment means of the payment gateway that enables to make payments through the China UnionPay (CUP) system. At the same time, the pattern of interaction between the online store and the payment gateway does not change.
Payment via UPOP is available for China UnionPay cardholders.
The integration pattern depends on the method of using the UPOP payment method.

  • The seller accepts payments via UPOP along with the use of e-commerce. In this case, the button to switch to the CUP system is located on the payment page, where the client is redirected to pay for the order. A description of the payment process is provided in the "Using CUP and e-commerce" section.

  • The seller accepts payments only through UPOP. In this case, a payment request via UPOP is created to redirect the client to the CUP system. A description of the payment process is provided in the "Using UPOP only" section.
    The CUP system does not provide for the possibility of two-phase payment.


Order payment scenarios

Using UPOP and e-commerce

If the store uses UPOP along with e-commerce, then when creating a payment page, in addition to the standard requirements described in the "Payment page layout" document, a requirement is added to place a button element on the page:
<input type="button" class="alfaclick" id="buttonPaymentUpop" value="Pay via UPOP" />"
By pressing the button, a request for payment using UPOP is made. The description of the request is presented in the sections:

  • Request for payment via an external payment system (WS),

  • Request for payment via an external payment system (REST).
    It is also possible to upload a standard payment page to the store, where a button is already placed to proceed to payment via UPOP.
    The main payment process through the CUP system is described below (negative scenarios are not taken into account):

  • 1. The client generates an order and confirms it;
  • 2. After the client confirms the order, the store registers the order in IPS. For registration, parameters such as the debit amount, the order number in the store's system (an alphanumeric value from 8 to 32 characters long), as well as the client's return URL are used. The request specification is presented in the following sections:
  • Request for order registration (WS), (in case of payment via UPOP, the order number in the store's system must be an alphanumeric value from 8 to 32 characters long);
  • Request for order registration (REST), (in case of payment via UPOP, the order number in the store's system must be an alphanumeric value from 8 to 32 characters long).
  • 3. IPS returns the order ID and the URL of redirecting the client to the payment form.
  • 4. The store sends the redirect to the URL received in step 3 to the client.
  • 5. The client opens the received URL by requesting a payment form.
  • 6. The client is redirected to the payment page owned by the Bank. The payment page displays the available method of payment via UPOP (the "Payment via UPOP" button).
  • 7. The client chooses payment via UPOP (clicks the button).
  • 8. The IPS system requests payment of the order in the UPOP payment gateway.
  • 9. The UPOP system requests data from the client for payment.
  • 10. The client sends their data.
  • 11. The UPOP system conducts the payment.
  • 12. The client is redirected to the page with the payment result.
  • 13. The client is redirected to the page with the payment result.
  • 14. The IPS system calls the UPOP system to check the payment status.
  • 15. The UPOP system checks the payment result and returns it to the IPS system.
  • 16. The Order status is updated in the IPS system.
  • 17. The result is displayed to the Client.

Using UPOP only

The main process of payment through the CUP system is described below (without negative scenarios) if the store accepts payment only through the CUP system:

  • 1. The client generates an order on the store's website.
  • 2.

    After the client confirms the order, the store registers the order in IPS. For registration, parameters such as the debit amount, the order number in the store's system (an alphanumeric value from 8 to 32 characters long), as well as the client's return URL are used. The request specification is presented in the following sections:

  • 3. IPS returns the order ID.
  • 4.

    The store sends a request for order payment to IPS via UPOP, transferring the order ID received in step 3. To do this, an alternative payment request is used with the mandatory transfer of the UPOP value in the paymentWay parameter, as well as the order ID. The request specification is presented in the following sections:

    • "Request for payment via an external payment system" (SOAP),
    • o "Request for payment via an external payment system" (REST).
  • 5. In response, the payment gateway sends a URL to redirect the client to the CUP system.
  • 6. The client's browser is redirected to the CUP system.
  • 7.

    The client's browser requests a form of authorization with the transfer of parameters:

    • Order ID (received in step 3);
    • BackURL to return to the order status request page (transferred in the request for order registration in step 2).
  • 8. The client receives an authorization form in the CUP system.
  • 9. The client fills out and submits the form to the CUP system.
  • 10. UPOP system conducts the payment.
  • 11. The client is redirected to the page with the payment result.
  • 12. The client is redirected to the page with the payment result.
  • 13. The IPS system calls the UPOP system to check the payment status.
  • 14. The UPOP system checks the payment result and returns it to the IPS system.
  • 15. The order status is updated in the IPS system.
  • 16. The result is displayed to the client.

Testing payment via UPOP

Testing process

To test making a payment via UPOP:

  • 1. Register the order in the payment gateway. Order registration can be carried out using REST/SOAP (the order number in the store's system transferred in the order registration request must be an alphanumeric value from 8 to 32 characters long).
  • 2.

    The transition to the CUP system is carried out:

    • After clicking the "Pay via UPOP" button on the payment page, if the client was redirected to it after registering the order,
    • After sending a request for payment via UPOP (REST/SOAP).
  • 3.

    The authorization page in the CUP system opens at http://202.101.25.184/beta/index.action?transNumber=201311062352028710592:

  • 4. Enter the card number and click "Next". The details of the test cards are given in the next section.
  • 5.

    The confirmation page opens:

  • 6. Enter the PIN and SMS confirmation code.
  • 7.

    Click "Confirm and Pay". A page opens with the payment result:

    When the Return Merchant button is clicked, one will be redirected back to the store page specified during the order registration in the returnUrl parameter (if registration was done via REST/SOAP), or in the return address parameter (when registering via the form).

  • 8. After that, the payment is considered formally completed. Upon returning to the store's website after payment, the payment status is not transferred in the CUP system. Therefore, in order to clarify the payment status, the store needs to poll the IPS system through a standard order status request (getOrderStatus) and wait for the order to go to the DEPOSITED state (funds are debited).

China UnionPay Test Cards

The cards presented in this section are intended only for testing payment via UPOP:
Debit cards:

Type of card information Meaning
Card number 6223 1649 9123 0014
Mobile phone number +130 12345678
PIN 111111
CVN2 123
Expiration Date month 12 year 33
SMS Code on PC 111111
SMS Code on Mobile 123456
Type of card information Meaning
Card number 6250 9470 0000 0014
Mobile phone number +852 11112222
CVN2 123
Expiration Date month 12 year 33
SMS Code on PC 111111
SMS Code on Mobile 123456

A card issued outside of China:

Type of card information Meaning
Card number 4938 8112 3456 2006
Mobile phone number 11112222
CVN2 123
Expiration Date month 11 year 22
SMS Code on PC 111111

Refund of payment funds for UPOP orders

A full or partial refund for orders paid through UPOP is carried out by standard means:

  • Through the administrative console (a description is provided in the document "Instructions for working with the console", section "Working with orders");

  • Using the API, through REST/SOAP interfaces. The request specification is presented in the following sections:

Payment using Apple Pay

Currently, payments are supported using mobile apps. Also, the seller can place a special button on its website that allows accepting payments through the Apple Pay system. The description of the preparation of the seller's website for accepting Apple Pay payments is not included in the objectives of this document.

Seller's actions required to connect to Apple Pay

Actions in the personal area of the payment gateway

Before accepting payments using Apple Pay, generate a key pair in your personal area and upload a public key certificate signing request.
The procedure is described in the Administrator's instructions for working with the console.

Creating Merchant ID

To create your Merchant ID (Seller's identifier), follow these steps.
To complete this procedure, you must have an Apple Developer account.

  • 1. In the Apple Member Center (Partner Center) personal area, go to Certificates, Identifiers & Profiles (Certificates, Identifiers & Profiles).
  • 2. On the displayed page in the Identifiers (section on the left, selectMerchant IDs .
  • 3. On the page that appears, click the + (Add) icon in the upper right corner.
  • 4.

    In the Merchant ID Description and Identifierfields, enter a description of your Apple Merchant ID and the ID itself, respectively.
    Note. The identifier should start with the word merchant, while specifying the address of your main website in reverse order. For example, for sale.test.ru website the ID will have the merchant.ru.test.sale value.

  • 5. Click Continue .
  • 6. On the page that appears, check the entered data and click Register.
  • 7. On the page that appears, click Done.

    • This value must be specified in the Apple Id field in the personal area of the internet acquiring in the "Working with Apple Pay keys" section

Creating a certificate for Merchant ID

To create a certificate for your Merchant ID, follow these steps.

  • 1. In the Apple Member Center (Partner Center) personal area, go to Certificates, Identifiers & Profiles.
  • 2. On the displayed page in the Identifiers section on the left, select Merchant IDs.
  • 3. Select your Merchant ID from the list and click Edit.
  • 4. Click Create Certificate in the Apple Pay Payment Processing Certificate block, then click Continue.
  • 5.

    Click Choose File specify the path to the certificate signing request file downloaded from the payment gateway's personal area.
    Note. The procedure for creating a certificate signing request file is presented in the "Administrator's instructions for working with the console" document.

  • 6. Click Generate.
  • 7. Click Download to download the created certificate to your computer.
  • 8.

    After downloading the certificate click Done.

    This certificate must be used to interact with Apple Pay, it does not need to be added to the personal area of Internet acquiring.

    If you have completed the above steps, you can start developing the interaction of your mobile app or website with the payment gateway.

Pattern of interaction when paying with Apple Pay

When paying using Apple Pay, the interaction takes place according to the following pattern.

The pattern description is given below.

  • 1. The user chooses the option of payment using Apple Pay.
  • 2. Information about the payment is sent to the Apple Pay system for processing.
  • 3. To process the payment data, a PKPaymentToken Object is created in the Apple Pay system, which contains the paymentData property (for more information, see Apple Pay documentation - in English).
  • 4. Apply Pay sends a response to the seller (mobile app or website).
  • 5. The seller extracts the paymentData property from the received PKPaymentToken Object and encodes its contents in Base64.
  • 6. . The seller creates a payment request containing, among other things, the paymentData property received from the Apple Pay system response and encoded in Base64, and sends it to the payment gateway for processing - see the Request for Payment via Apple Pay (Web Service) and Request for Payment via Apple Pay (REST) sections.
  • 7. The payment gateway processes the request.
  • 8. The payment gateway returns a response with the result.
  • 9. The mobile app or website displays the payment result to the user.

Making recurring payments via Apple Pay

To initiate recurrent payments, one needs to create an appropriate binding. To do this, one need to make a payment request and specify the clientId clientId value in the request:

For subsequent requests for recurrent payments, the recurrentPayment request is used:

Apple Pay - links to reference information

The table below provides links to the reference information about Apple Pay.

Description Link
A section of the Apple.com webite containing general information about Apple Pay. https://www.apple.com/apple-pay
A section of the Apple.com, website intended for developers and containing links to various documents and background information related to Apple Pay. https://developer.apple.com/apple-pay
A section of the Apple.com website containing information about testing. https://developer.apple.com/support/apple-pay-sandbox
A PDF document containing general information about Apple Pay and links to reference information. https://developer.apple.com/apple-pay/Getting-Started-with-Apple-Pay.pdf
A PDF document containing recommendations for the design of websites and mobile apps in the Apple style. https://developer.apple.com/apple-pay/Apple-Pay-Identity-Guidelines.pdf
A section of the Apple.com website containing a programming reference. https://developer.apple.com/library/ios/ApplePay_Guide
A section of the App Store reference guide dedicated to Apple Pay apps.. https://developer.apple.com/app-store/review/guidelines/#apple-pay
API Reference (programming interface for apps). https://developer.apple.com/library/ios/documentation/UserExperience/Reference/PassKitFramework/index.html#//appleref/doc/uid/TP40012158
Description of the PKPaymentToken Object structure. https://developer.apple.com/library/ios/documentation/PassKit/Reference/PaymentTokenJSON/PaymentTokenJSON.html#//apple_ref/doc/uid/TP40014929
The login page for the development environment. https://devforums.apple.com/community/ios/connected/applepay

Scenario for Apple Pay payment from the payment page on the payment gateway side


  • 1. The client generates an order on the seller's website.
  • 2.

    The seller registers the order in the payment gateway.

  • 3. The payment gateway returns the unique order number in the payment gateway system and the URL to which the client needs to be redirected.
  • 4. The store's system redirects the client's browser to the URL received in step 3.
  • 5. The client's browser opens the URL.
  • 6. As a page at the specified URL, the client's browser receives a payment form.
  • 7. The client chooses the Apple Pay payment method (the button is displayed on devices that support Apple Pay payment).
  • 8. Data is exchanged between the payment gateway and the Apple Pay system - the payment gateway receives payment data.
  • 9. The payment gateway makes the payment.
  • 10. The client is redirected to the final page of the store.
  • 11. The client's browser opens the final page.
  • 12. The status is displayed and shown to the client.

Payment using Google Pay

Introduction

There are several options for implementing the possibility of payment using the Google Pay system.

Implementation of the payment method Description
From the mobile app Payment is made from the mobile app from the user's mobile device. In this scenario, the app requests encrypted data from Google Pay. This data must be transferred to the payment gateway.
Payment scenario with user redirection to ACS If the user has chosen the payment option via Google Pay with a non-tokenized card, in response to the payment request, data will be returned to the payment gateway to redirect the user to the issuer's ACS. The interaction pattern is presented below.
From a web page, while the payment page is located on the seller's side Payment is made from a web page. The user selects payment on the seller's website, while the seller requests encrypted payment data from the Google Pay system. Then the seller must send this data to the payment gateway.
From a web page, while the payment page is located on the side of the payment gateway Payment is made from a web page. The seller redirects the user to the payment gateway page, then the payment gateway exchanges data with the Google Pay system, after which the payment is made.

Scenario of payment in the mobile app


  • 1. The client chooses the Google Pay payment method.
  • 2. The app requests information from Google Pay about masked card data.
  • 3. Google Pay returns masked card data to the app.
  • 4. The app displays the masked data of the card added to Google Pay to the client.
  • 5. The client confirms the payment using the card added to Google Pay.
  • 6. The app requests encrypted card data from Google Pay.
  • 7. Google encrypts data using a public key - the corresponding private key is located in the payment gateway.
  • 8. Google returns encrypted payment data to the app.
  • 9.

    The appl sends a Google Pay payment request to the payment gateway, indicating the token received from the Google Pay system:

  • 10. The payment gateway decrypts the received token and makes the payment.
  • 11. The payment gateway returns the payment result to the app.
  • 12. The app displays the payment result to the client.

Payment scenario with user redirection to ACS


  • 1. The client chooses the Google Pay payment method.
  • 2. The app requests information from Google Pay about masked card data.
  • 3. Google Pay returns masked card data to the app.
  • 4. The app displays the masked data of the card added to Google Pay to the client.
  • 5. The client confirms the payment using the card added to Google Pay.
  • 6. The app requests encrypted card data from Google Pay.
  • 7. Google encrypts data using a public key - the corresponding private key is located in the payment gateway.
  • 8. Google returns encrypted payment data to the app.
  • 9.

    The appl sends a Google Pay payment request to the payment gateway, indicating the token received from the Google Pay system:

  • 10. The payment gateway decrypts the received token and checks the card whether it is tokenized or not.
  • 11. Provided that the card is enroled in 3-D Secure, the payment gateway sends a response to the payment request, which contains a redirect link to the ACS server.
  • 12. The user is redirected to the ACS website.
  • 13.

    The user goes to the ACS website and authenticates.

    In order for the client to get to the ACS page, the seller redirects them to the payment gateway page of the following type:
    https://web.rbsuat.com/ab/acsRedirect.do?orderId=< >, where < > is the client's unique order number.

  • 14. After successful authentication, the user is redirected from the ACS website to the payment gateway page.
  • 15. The user goes to the payment gateway page.
  • 16. The payment gateway returns the payment result.


Seller's actions required to connect Google Pay to the app

Before accepting payments using Google Pay, please read all the Google requirements and conditions.


Connecting an Android app to the Google Pay API:


Connection documentation:


Recommendations for connecting an Android app to Google Pay:


Scenario of payment with a payment page on the Seller's side

If the payment page is located on the Google Pay side, the payment takes place according to the following pattern.

  • 1. The client forms an order on the website of the online store and chooses the Google Pay payment method.
  • 2. The online store system generates a request for payment in Google Pay.
  • 3. The Google Pay system generates encrypted payment data.
  • 4. The online store system receives the encrypted payment data
  • 5.

    The online store system generates a request to the payment gateway for Google Pay payment, indicating the encrypted payment data received:

  • 6. The payment gateway decrypts the received data and makes the payment.
  • 7. IPS returns the payment result to the online store system.
  • 8. The payment result is displayed to the client.


Seller's actions required to connect Google Pay to a web page

Before accepting payments using Google Pay, please read all the Google requirements and conditions.


Connecting a web page to the Google Pay API:


Connection documentation:


Recommendations for connecting a web page to Google Pay:


Scenario of payment with a payment page on the payment gateway side


  • 1. The client generates an order on the seller's website.
  • 2.

    The seller registers the order in the payment gateway.

  • 3. The payment gateway returns the unique order number in the payment gateway system and the URL to which the client needs to be redirected.
  • 4. The store's system redirects the client's browser to the URL received in step 3.
  • 5. The client's browser opens the URL.
  • 6. As a page at the specified URL, the client's browser receives a payment form.
  • 7. The client chooses the Google Pay payment method and confirms their choice.
  • 8. Data is exchanged between the payment gateway and the Google Pay system - the payment gateway receives payment data.
  • 9. The payment gateway makes the payment.
  • 10. The client is redirected to the final page of the store.
  • 11. The client's browser opens the final page.
  • 12. The status is displayed and shown to the client.

Payment using Samsung Pay

Preliminary actions

Before accepting payments via Samsung Pay, the seller must register on the Samsung partner portal. After that, in the personal area of the payment gateway, the seller must generate a key pair, export the certificate signing request and upload it to the Samsung partner portal.

Pattern using a mobile app

Below is a pattern of interaction when making a payment using a mobile app.

  • 1. The payer chooses the Samsung Pay payment method.
  • 2. The app sends payment details to Samsung.
  • 3. Samsung checks the app.
  • 4. Samsung sends a response to the app containing, among other things, the 3ds.data parameter with encrypted payment data.
  • 5. The seller sends a payment request to the payment gateway, while the paymentToken parameter includes the content of 3ds.data received from Samsung:
  • Request for payment via Samsung Pay (WS).
  • Request for payment via Samsung Pay (REST).
  • 6. The payment gateway decrypts the contents of the paymentToken and makes the payment.
  • 7. The payment gateway sends the payment result to the app.
  • 8. The app displays the result of the payment to the payer.