Single Immediate Payments
A single immediate payment (SIP) is a payment initiated on behalf of a user for immediate execution.
Note: We support immediate transfer token redemption through Bank-initiated payments.
For information regarding
TPP-initiated SIP (2-step)
The following diagram shows the communication flow for a single immediate payment (click to enlarge):
Note: If you would prefer to use the auto redeem functionality to automatically redeem authentication tokens for 2-step payments, see Optional features for more information.
Guidance for making the appropriate POST and GET calls, as well as handling the bank's responses to these requests is covered next.
Base URLs
See Base URLs.
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
- Member ID – unique value generated by the 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.
You can obtain the values from the dashboard by following these steps:
-
If the dashboard isn't already open in a browser tab, sign in.
-
Click Member Information in the navigation panel on the left.
-
Click the "eye" icon to the right of each value to reveal it.
-
Copy the value you need.
If the selected bank imposes this initial credentials check requirement, you'll need to capture the credentialFields
specified by the bank (e.g., the user's ) in its response to your GET /banks
call (see Bank Selection) and include this information in your payment request.
In addition, when initial credentials are required by the user-selected bank, the redirect URL in the sandbox will be:
https://tpp-integration.sandbox.token.io/initiatePayment/callback?redirect-url={{your-redirect-url}}
For production, the redirect URL changes to:
https://tpp-integration.token.io/initiatePayment/callback?redirect-url={{your-redirect-url}}
Here, {{your-redirect-url}} is your standard TPP redirect URL.
The exchange iterations necessary to provide initial credential information to the bank take place in the background.
If you are not connecting to a bank in Germany, Austria or Hungary, the requirement for an initial credentials check using the redirect URL format above does not apply and you should instead use the standard format outlined below.
{
"requestPayload"
: {
"refId"
: "xyz"
, // must be unique
"to"
: {
"id"
: "m:nP4w3u5y8ddrxDJkjimgSX9e4fZ:5zKtXEAq"
// required
member ID; mandatory
},
"transferBody"
: {
"currency"
: "EUR"
,
"lifetimeAmount"
: "1.00"
,
"instructions"
: {
"transferDestinations"
: [
{
"sepa"
: {
"iban"
: "FR7630004001160000784013521"
},
"customerData"
: {
"legalNames"
: [
"Test"
// populating creditor name is mandatory
]
}
}
]
}
},
"description"
: "your description",
"redirectUrl"
: "https://sample-merchant-domain.com/transfer"
}
}
"Available from Dashboard" indicates a value that can be looked up in the Dashboard under Settings > Member Information.
The most important request fields and their corresponding descriptions are listed in the following table.
Field | Description/Subfields | Required/Optional | |||
---|---|---|---|---|---|
refId |
refId maps to tppRefId in the bank's consentRequest. It is needed to match/verify the originating token request with the bank's consent request. |
Required | |||
to | Identifies the member initiating the request | Required | |||
id | Member ID of the |
Required | |||
alias |
A human-readable proxy for your member identifier that contains your realmId or alias type (DOMAIN, EMAIL, other) and a value string.
A realmId identifies a member created under the realm of a specific bank. See Member Information in Understanding Dashboard Settings to find your member id and alias. |
Optional; soon to be deprecated | |||
transferBody | Specifies the critical details of the transfer payload: currency, lifetimeAmount, and transferDestinations |
Required | |||
currency | ISO 4217 currency code for the transaction | Required | |||
lifetimeAmount |
Amount of the payment/transfer valued in currency.
Precision: Recommended precision is rounding to 4 decimal places (HALF-EVEN), although the TPP can set it's own desired precision. However, be aware that certain banks may handle rounding differently — some with greater precision (i.e., more decimal places), others with reduced rounding precision (fewer decimal places). The Token Platform strictly serves as the pipeline between the TPP and the bank, imposing no precision restrictions. |
Required | |||
instructions | Specifies beneficiary account information and any additional transfer instructions. | Required | |||
|
Required | ||||
callbackState |
Developer-specified string allowing state to be persisted between the request and callback phases of the flow; used for the signature in a GET /token-requests/{tokenRequestId}/token-request-result call, in which the signing payload for the signature is a combination of state and tokenId and validates the tokenId against the callbackstate originally sent by the TPP in the request. Note: The value of callbackState is added to the redirect URL and appended to the hash of the CSRF token specified by the bank; e.g.: https://{callback-url}?signature=%7B%22memberId%22%3A%22m%3A3rKtsoKaE1QUti3KCWPrcSQYvJj9% |
Optional | |||
description |
Description of the payment with the following qualifiers:
This description field maps to description in the bank's consentRequest presented to the user. Warning: If description in a subsequent token request for lookups/changes/updates (retrieve, redeem, or cancel) doesn't match the description in the originating token request, an exception will be thrown. |
Optional, with the caveats described in the previous column | |||
disableFutureDatedPaymentConversion | Explicitly disables conversion of an auto single immediate payment to a future-dated payment for requests sent during the bank's out-of-operation hours. Default = false, which means always allow auto SIP to FDP conversion. Set to true, conversion is disabled | Optional | |||
redirectUrl |
Defines the |
Required | |||
traceID | TPP-provided unique value captured by Token.io and sent across to the bank to be stored with the request throughout its lifecycle as an audit-trail aid. | Optional | |||
requestOptions |
|
Optional | |||
*Inclusion of some elements may be optional or bank-dependent |
Cited in the table within transferInstructions
and nested in source
is the accountIdentifier
object (required):
"source": {
"
": { "gb_domestic
": {
"account_number
": "70000005",
"sort_code
": "700001"
}
}
}
Remember, whatever you specify as the source
and transferDestinations
in the request will be reflected in the response.
A PAN is disallowed in the token request payload within the refId
and description
fields. In accordance with the PA-DSS security standard, Regex is used for pattern matching of numeric strings that intentionally or inadvertently reveal or resemble a PAN in the refId
or description
of a token request. Potential PAN patterns found will now throw an exception.
Payee Information
customerData
within providerTransactionDetails
for single transactions.
-
STET requires creditor account information.
-
CMA9, NextGenPSD2, and PolishAPI have the creditor name and account identifiers, as well as the creditor agent BIC. 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.
If you are initiating a payment to Barclays Bank UK or HSBC, the creditor name (creditorAcount.name
) can be no more than 18 characters. If this limit is exceeded, the bank will reject the payment.
Otherwise, when providing creditor name and address for CMA9 international payments, bear in mind that certain banks, such as HSBC, require creditor information to process international payments, despite its designation as "optional" in the OBIE specification. To be safe with respect to CMA9 international payments, provide this information in the customerData
fields of the transferDestination
object. The OBIE information maps to its Token.io counterpart as follows:
Token.io | OBIE |
---|---|
flats
|
SubDepartment
|
house_name
|
Department
|
house_number
|
BuildingNumber
|
street
|
StreetName
|
post_code
|
PostCode
|
city
|
TownName
|
district
|
CountrySubDivision
|
country
|
Country
|
Processing the Response
Here's an example of the response you'll receive:
"tokenRequest"
: {
"id"
: "rq:3g5RVV7Z4oU9P5rtzX2YhnssuPC5:5zKtXEAq"
, // request-id; add to BASE_URL for consent
"requestPayload"
: {
"to"
: {
"alias"
: {
"type"
: "EMAIL"
,
"value"
: noverify@token.io"
}
"id"
: "m:nP4w3u5y8ddrxDJkjimgSX9e4fZ:5zKtXEAq"
//
member ID
},
"transferBody"
: {
"currency"
: "EUR",
"lifetimeAmount"
: "10",
"transferInstructions"
: {
"transferDestinations"
: {
"fasterPayments"
: {
"accountNumber
": "70000005",
"sortCode
": "700001"
}
}
}
},
"description"
: "your description",
"redirectUrl"
: "https://sample-
merchant-domain.com/transfer"
}
}
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.
https://{{BASE_URL}}/app/request-token
/{{Insert request-id here
}}
// example = https://web-app.sandbox.token.io/app/request-token/rq:3RKfCA7KQEEZERLoFsAt3MoAnoP5:5zKtXEAq
For banks where the open banking standard field is set to token
(POST /transfers
payload.transferDestinations.token
), you should not call the POST /authorization
call.
Instead, the user should be redirected using the redirect URL, as above.
You can specify a particular language by passing its language code (lang=country-code
) as a query parameter, appended to the URL above, which the user can override in the Web App according to personal preference. Here's an example for passing the desired ISO 639-1 language code for German (de
):
https://web-app.token.io/app/request-token/rq:o9adbFqJXcaDGNDaykPvpSZFZDW:5zKtXEAq?
Upon user consent, the bank will redirect the user back to the
"redirectUrl": "https://sample-merchant-domain.com"
/pis?tokenId=sample_token_id
To derive the complete redirect URL, you'll need to URL decode the value provided.
Using the tokenId sent by the bank, which confirms user consent, you can now initiate payment.
For two-step payments, you'll need to redeem the transfer token with a POST /transfers request containing the the bank-provided tokenId. Here's an example:
{
"payload"
: {
"tokenId"
: "{{TOKEN_ID}}"
, // tokenId in redirectUrl
}
}
The request field and its corresponding description are listed in the following table.
Field | Description/Subfields | Required/Optional | ||
---|---|---|---|---|
payload
|
tokenId
|
Bank-generated identifier returned in the response to the original payment request | Required |
You'll receive a transferId and transferStatus in a callback, which you can then display to the customer/user.
POST
and GET
calls must pass in an appropriate authorization header containing your authentication key (see Common Request Headers).
Please refer to the API reference for additional details on all of the above.