Global API | Volt Docs

How it works?

The Volt Global API serves as the cornerstone of Volt’s infrastructure.

Our goal is to provide you with the flexibility to integrate with our system on your own terms. Whether you choose a hosted checkout integration or prefer to build your own custom UI, the Volt Global API empowers you to do so.

Payment initiation flow

One of the foundations of the Global API it is convenience of use. New API steers you through the whole payment initiation flow, allowing seamless integration, despite the integration channel/type used. It is done by returning paymentInitiationFlow object in the API responses. This object determines where payment request is in the flow, and what needs to be done next.

Example of "paymentInitiationFlow" object

{
    // ...
    "paymentInitiationFlow": {
        "status": "PROCESSING",
        "details": {
            "reason": "AWAITING_USER_REDIRECT",
            "redirect": {
                "url": "https://vo.lt/AB1XF",
                "directUrl": "https://myBank.com/authorisation?code=xyz"
            }
        }
    }
}

Payment initiation flow usually consists of two elements: payment authorisation (payer logs in within the institution and authorises the payment) and payment initiation itself. This flow can be boiled down to a simple state machine:

State machine determines possible transitions and paths between statuses of the initiation flow. More details about statuses and their description can be found here.

Authorisation flows

Authorisation flow, where the payer authorises the payment, is a part of payment initiation flow. Authorisation flows comes in many flavours, depending on the institution, as it is the institution that determines which authorisation flow will be used.

There are three main authorisation flows:

Redirect

With the redirect authorisation flow, the payer is redirected to the institution UI to authenticate and authorise the payment.

Pre-authorisation

With the pre-authorisation flow authentication with the institution and authorisation of the payment are two separate steps. Usually, the payer is redirected to the institution UI to authenticate with the institution, and then is redirected to the institution UI again to authorise the payment.

Embedded

With the embedded authorisation flow a payer’s credentials to the institution are captured by you or Volt, which are then used for authentication at the institution. There is no redirect to the institution.

Decoupled authorisation

All mentioned authorisation flows can incorporate an additional step of authorisation. It is called decoupled authorisation.

With the decoupled authorisation the payer needs to authorise the payment through an additional form of authorisation provided by the institution, outside of the API integration (hence the name decoupled). Additional authorisation is done using whatever solution institution supports. In most scenarios it is done via mobile phone.

Regional specifics

Depending on the region you’re operating, some different input might be required. This is due to local regulations and requirements regarding payment processing. Global API helps in navigating between different regions, having integrating only once. This is done by wrapping region-specific input within dedicated objects.