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 delayed capture

The payment session​

All API operations are carried out within a payment session: session. 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. 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 a session/start/payment request.
  2. Bank 131 will send you a ready_to_confirm webhook, which means that the Bank is ready to make the payment and is waiting for your confirmation.
  3. Confirm (session/confirm) or cancel (session/cancel).

These steps are necessary only when paying without the widget​

  1. If you are making a payment without a payment form, Bank 131 will send you an 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 3D Secure.
  2. Redirect the user to the address for payment confirmation (3D Secure).

These steps are only required for delayed capture payments​

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

  1. Bank 131 will send you a 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 (session/cancel).
  1. Bank 131 will send you a 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 acquiring_payments 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.