Single Immediate Payments

A single immediate payment (SIP) is a payment initiated on behalf of a PSU for immediate execution. There are, however, certain restrictions imposed by the various payment systems. For instance, SEPASingle Euro Payments Area – a payments system created by the European Union (EU) which harmonizes the way cashless payments transact between euro countries. European consumers, businesses, and government agents who make payments by direct debit, instant credit transfer, and through credit transfers use the SEPA architecture. The single euro payment area is approved and regulated by the European Commission. SEPA currently includes 36 members. It encompasses the 28 EU member states along with Iceland, Norway, Liechtenstein, Switzerland, Andorra, Vatican City, Monaco and San Marino. The single euro payment area remains an ongoing, collaborative process between these parties. SEPA is in the process of harmonizing rules regarding mobile and online payments. transfers have a 3:00 pm cutoff time for same day processing. Requests received after this time will be processed the following business day. It's also important to note that, as a general rule, sending euros outside the UK using SEPA can take up to 2 business days before being credited to the beneficiary bank, although in most cases the money arrives in the beneficiary's bank account on the next business day.

Bank-initiated SIP (1-step)

Putting the full sequence into perspective, the diagram pictured next (hover to enlarge) shows the communication flow for a bank-initiated single immediate payment.

TPP-initiated SIP (2-step)

The sequence diagram pictured next shows the communication flow for a TPP-initiated single immediate payment.

Guidance for making the appropriate POST and GET calls, as well as handling Token's responses to these requests is covered next.

Base URLs

See Base URLs.

Headers

See Common Request Headers.

Making a Transfer Token Request

To initiate a payment request with the bank, you'll need to be able to identify yourself as the calling TPP using your Member ID and your Alias, defined as follows:

• Member ID – unique value generated by the Developer Dashboard when you signed up.
• Alias – unique email, domain, eIDAS or realmId you provided when you signed up.

A transfer request must include both parameters.

Once the PSUPayment Services User – an individual person or legal business entity making use of an Open Banking service as a payee, payer or both. gives consent for you to initiate PIS on the PSU's behalf, here's a simplified call for POSTing /token-requests with a requestPayload:

The most important request fields and their corresponding descriptions are listed in the following table.

 

Remember, whatever you specify as a transferDestination in the request will be reflected in the response.

Payee Information

Submission and return of payee information is not supported by all banks. When supported, and based on the standard adopted by the bank, creditor account (payee) information (legal name and/or address) is included in customerData within providerTransactionDetails for single transactions. When included in the request, payee/creditor account information is available in the response, regardless of the API standard adopted by the bank; typically, however, the following guidelines apply:

• STETCreated according to the new Payment Services Directive (PSD2), this API aims to provide a secure and easy-to-use set of services to be implemented by European ASPSPs. requires creditor account information.
• CMA9As part of the Open Banking initiative, the CMA9 are the nine largest banks in the UK as determined by the Competition and Markets Authority (CMA). The CMA is an independent department of the UK government chartered to promote market competition and fairness, and reduce any harmful monopolies., NextGenPSD2Common API standard for PSD2 developed by the Berlin Group to create uniform and interoperable communications between banks and TPPs., and PolishAPIThe PolishAPI standard is the key part of the Open Banking on the Polish financial market. It is defining the interface enabling third parties to access payment accounts, based on amended directive on payment services in the internal market (PSD2). have the creditor name and account identifiers, as well as the creditor agentFinancial institution servicing an account for the creditor.BICBank Identifier Code – a unique identifier for a specific financial institution. A BIC is composed of a 4-character bank code, a 2-character country code, a 2-character location code and an optional 3-character branch code.. However, these are optional fields, so the presence of creditor account information is bank-dependent.
• CMA9 needs the creditor agent address, whilst PolishAPI requires the creditor's address.

 

Making a Gateway Request "on behalf of" – Using the actingAs Property

Resellers and TPPs contractually granted permission by Token can create a token on behalf of another party by configuring the actingAs object in the requestPayload. Here's an example:

Each identifier is defined in the following table:

A "gateway" is a business member empowered to act on behalf of a merchant that is not registered as a member in the Token system. The gateway member must have ACT_ON_BEHALF_OF permission from Token and populate the actingAs field in the token request accordingly to indicate the merchant on whose behalf it is acting.

Processing the Response

Here's an example of the response you'll receive:

Create the redirect URL by appending the request id in the response (shown above in red) to the redirect base URL, then send it to the user to provide explicit consent to the bank.

Upon user consent, Token will redirect the user back to the TPP with either a tokenId (also known as the consent-id on the bank side) or a transferId as a query parameter, depending on the bank's support for two- or one-step payments, respectively.

Using the tokenId sent by the bank, which confirms PSU consent, you can now initiate payment.

If the bank supports one-step payments, the callback will contain a transferId and a transferStatus (see Payment Status: Value and Meaning for the list of possible status codes), which you can then display to the customer/user. Use the transferId, as necessary, to check for status updates with a GET /transfers/{transferId} call, presuming you didn't subscribe to a webhook in the original token request.

For two-step payments, you'll need to redeem the transfer token with a POST /transfers request containing the Token-provided tokenId. Here's an example:

The most important request fields and their corresponding descriptions are listed in the following table.

You'll receive a transferId and transferStatus in a callback, which you can then display to the customer/user.

To get information about a specific token, use a GET /tokens/{tokenId} call. To subsequently retrieve information about a specific payment, use a GET /transfers/{transferId} call.

Please refer to the API's Swagger Reference for additional details on all of the above.