Skip to main content

Payment process

How you can perform payments

  • through the payment form (if you do not have PCI DSS)
  • with open parameters (if you have PCI DSS)
  • with later capture

The payment session

All API operations are carried out within a payment session: PaymentSession. One payment session can include several operations: for example, you can accept and then refund a payment.

You can send payments using one of the two options:

  • initiating the payment when you start a session (as a single request session/init/payment)
  • starting a session and then performing a payment (as two requests, session/create and session/start/payment) e.g. to call the payment form widget or just to obtain the session identifier and use it to monitor what is happening with the payment.

Main payment scenario

  1. You create a payment session:
  • separately from the payment itself (session/create), which is mandatory if you are going to perform the payment using the payment form widget;
  • or simultaneously with the payment (session/init/payment).

These steps are necessary only when paying with the widget

  1. If you are going to connect the payout form widget, you will need to send a request for token creation to access the JavaScript library.
  2. You show the widget to the user and obtain their card details.
  1. If you are not using the widget and have created the session separately from the start of the payment, you need to send the session/start/payment request.
  2. Bank 131 sends you the ready_to_confirm webhook, which means that the Bank is ready to make the payment and is waiting for your confirmation.
  3. You confirm (confirm_request) or cancel (cancel_request).

These steps are necessary only when paying without the widget

  1. If you are making a payment without a payment form, Bank 131 sends you the action_required webhook. This means that you will need to take additional action to perform the payment. For instance, the user might need to go through 3-D Secure.
  2. Redirect the user to the address for payment confirmation (3-D Secure).

These steps are only required for payments with later capture

Upon a payment with later capture, funds are frozen on the user card and debited on your command. If you don't want to perform payments with later capture, you can skip these steps. To follow this scenario, contact a Bank 131 manager.

  1. Bank 131 sends you the ready_to_capture webhook. This means the funds to be used for the payment are frozen on the user's bank card.
  2. Debit the captured amount (session/capture) or cancel the hold (cancel_request).
  1. Bank 131 sends you the payment_finished webhook containing the result of the payment. If the status is succeeded, this tells you that the payment was successful.

Payment statuses

The status of the payment is returned in the status field of the AcquiringPayment object. To query it, wait for a webhook from Bank 131 or send a session/status request with the identifier of the session containing this payment.

Possible payment statuses

  • in_progress — the payment is being processed;
  • pending — the payment is waiting to be confirmed;
  • succeeded — the payment has completed successfully;
  • failed — an error occurred while processing the payment.