Payment Initiation request

post https://test-api.tbcbank.ge/xs2a-sandbox/v1/{payment-service}/{payment-product}

Create a payment or bulk-payment initiation resource addressable under paymentId with all data relevant for the corresponding payment product.

This is the first step in the API to initiate the related payment

To initiate a payment initiation request at the ASPSP can be sent with a JSON body depending on the payment product in the path.

There are the following payment products:

Payment products with payment information in JSON format:
- aspsp - for payments between own accounts
- domestic - for payments between TBC and Georgian banks
- foreign - for payments between TBC and Foreing banks

Furthermore the request body depends on the payment-service:

payments: A single payment initiation request.
bulk-payments: A collection of several payment initiation requests.

In case of a JSON there are several JSON payment blocks contained in a joining list.

time	status	user agent
Retrieving recent requests…

Loading…

Path Params

payment-service

string

required

The payment service, which type of payment service TPP want.

Possible values are:

payments - A single payment initiation request.
bulk-payments - A collection of several payment initiation requests.

payment-product

string

required

The addressed payment product endpoint.

The following payment products are supported:

aspsp - for payments between own accounts
domestic - for payments between TBC and Georgian banks
foreign - for payments between TBC and Foreing banks

Body Params

Headers

Consent-ID

string

This data element may be contained, if the payment initiation transaction is part of a session, i.e. combined AIS/PIS service.
This then contains the consentId of the related AIS consent, which was performed prior to this payment initiation.

X-Request-ID

uuid

required

ID of the request, unique to the call, as determined by the initiating party.

Digest

string

required

Is contained if and only if the "Signature" element is contained in the header of the request.

X-JWS-Signature

string

required

A signature of the request by the TPP on application level.

PSU-ID

string

Identity number of user to identify client in ASPSP systems.

PSU-Corporate-ID

string

Identity number of corporate user to identify corporate client in ASPSP systems.

PSU-IP-Address

string

required

The forwarded IP Address header field consists of the corresponding HTTP request IP Address field between PSU and TPP. It shall be contained if and only if this request was actively initiated by the PSU.

Accept-Language

string

HTTP header indicates the natural language and locale that the client prefers.

TPP-Redirect-URI

uri

required

URI of the TPP, where user will be redirected to after accepting payment.

TPP-Explicit-Authorisation-Preferred

boolean

If it equals "true", the TPP prefers to start the authorisation process separately.
If it equals "false" or if the parameter is not used, there is no preference of the TPP.
This especially indicates that the TPP assumes a direct authorisation of the transaction in the next step.

TPP-Rejection-NoFunds-Preferred

boolean

If it equals "true" then the TPP prefers a rejection of the payment initiation in case the ASPSP is providing an integrated confirmation of funds request an the result of this is that not sufficient funds are available.

If it equals "false" then the TPP prefers that the ASPSP is dealing with the payment initiation like in the ASPSPs online channel, potentially waiting for a certain time period for funds to arrive to initiate the payment.
This parameter might be ignored by the ASPSP.

TPP-Redirect-Preferred

boolean

If it equals "true", the TPP prefers a redirect SCA approach.
If it equals "false", the TPP prefers not to be redirected for SCA. The ASPSP will consider the Decoupled SCA approach, depending on the parameter TPP-Decoupled-Preferred.

The parameter is required to be false, if TPP prefers to use decoupled SCA aproach and TPP-Decoupled-Preferred is "true".

If the parameter is not used, ASPSP will consider Redirect SCA Approach.

TPP-Decoupled-Preferred

boolean

If it equals "true", the TPP prefers a decoupled SCA approach.
If it equals "false", the TPP prefers not to use the decoupled approach for SCA. The ASPSP will consider redirect as SCA approach.

The parameter is required if TPP prefers to use decoupled SCA aproach.

If both parameters TPP-Redirect-Preferred and TPP-Decoupled-Preferred are present and true, the request is still not rejected and ASPSP will consider Redirect SCA Approach.

PSU-IP-Port

string

The forwarded IP Port header field consists of the corresponding HTTP request IP Port field between PSU and TPP, if available.

PSU-Geo-Location

string

The forwarded Geo Location of the corresponding http request between PSU and TPP if available.

Responses

Response body

object

paymentId

string

Resource identification of the generated payment initiation resource.

transactionStatus

string

The transaction status is filled with codes of the ISO 20022 data table: - 'ACCC': 'AcceptedSettlementCompleted' - Settlement on the creditor's account has been completed. - 'ACCP': 'AcceptedCustomerProfile' - Preceding check of technical validation was successful. Customer profile check was also successful. - 'ACSC': 'AcceptedSettlementCompleted' - Settlement on the debtor�s account has been completed. Usage: this can be used by the first agent to report to the debtor that the transaction has been completed.
Warning: this status is provided for transaction status reasons, not for financial information. It can only be used after bilateral agreement. - 'ACSP': 'AcceptedSettlementInProcess' - All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution. - 'ACTC': 'AcceptedTechnicalValidation' - Authentication and syntactical and semantical validation are successful. - 'ACWC': 'AcceptedWithChange' - Instruction is accepted but a change will be made, such as date or remittance not sent. - 'ACWP': 'AcceptedWithoutPosting' - Payment instruction included in the credit transfer is accepted without being posted to the creditor customer�s account. - 'RCVD': 'Received' - Payment initiation has been received by the receiving agent. - 'PDNG': 'Pending' - Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed. - 'RJCT': 'Rejected' - Payment initiation or individual transaction included in the payment initiation has been rejected. - 'CANC': 'Cancelled' Payment initiation has been cancelled before execution Remark: This codeis accepted as new code by ISO20022. - 'ACFC': 'AcceptedFundsChecked' - Preceding check of technical validation and customer profile was successful and an automatic funds check was positive . Remark: This code is accepted as new code by ISO20022. - 'PATC': 'PartiallyAcceptedTechnical' Correct The payment initiation needs multiple authentications, where some but not yet all have been performed. Syntactical and semantical validations are successful. Remark: This code is accepted as new code by ISO20022. - 'PART': 'PartiallyAccepted' - A number of transactions have been accepted, whereas another number of transactions have not yet achieved 'accepted' status. Remark: This code may be used only in case of bulk payments. It is only used in a situation where all mandated authorisations have been applied, but some payments have been rejected.

ACCC ACCP ACSC ACSP ACTC ACWC ACWP RCVD PDNG RJCT CANC ACFC PATC PART

transactionFees

object

currency

string

ISO 4217 Alpha 3 currency code.

amount

string

The amount given with fractional digits, where fractions must be compliant to the currency definition.
Up to 14 significant figures.
Negative amounts are signed by minus. The decimal separator is a dot.

currencyConversionFee

object

currency

string

ISO 4217 Alpha 3 currency code.

amount

string

estimatedTotalAmount

object

currency

string

ISO 4217 Alpha 3 currency code.

amount

string

estimatedInterbankSettlementAmount

object

currency

string

ISO 4217 Alpha 3 currency code.

amount

string

transactionFeeIndicator

boolean

If equals true, the transaction will involve specific transaction cost as shown by the ASPSP in their public price list or as agreed between ASPSP and PSU.If equals false, the transaction will not involve additional specific transaction costs to the PSUunless the fee amount is given specifically in the data elements transactionFees and/or currencyConversionFees.If this data element is not used,there is no information about transaction fees unless the fee amount is given explicitly in the data element transactionFees and/or currencyConversionFees.

scaMethods

array of objects

This data element might be contained, if SCA is required and if the PSU has a choice between different authentication methods. Depending on the risk management of the ASPSP this choice might be offered before or after the PSU has been identified with the first relevant factor, or if an access tokenis transported. If this data element is contained, then there is also a hyperlink of type "startAuthorisationWithAuthenticationMethodSelection"contained in the response body.These methods shall be presented towards the PSU for selection by the TPP.

scaMethods

object

authenticationType

string

Type of the authentication method. More authentication types might be added during implementation projects and documented in the ASPSP documentation. - 'SMS_OTP': An SCA method, where an OTP linked to the transaction to be authorised is sent to the PSU through a SMS channel. - 'CHIP_OTP': An SCA method, where an OTP is generated by a chip card, e.g. a TOP derived from an EMV cryptogram. To contact the card, the PSU normally needs a (handheld) device. With this device, the PSU either reads the challenging data through a visual interface like flickering or the PSU types in the challenge through the device key pad. The device then derives an OTP from the challenge data and displays the OTP to the PSU. - 'PHOTO_OTP': An SCA method, where the challenge is a QR code or similar encoded visual data which can be read in by a consumer device or specific mobile app. The device resp. the specific app than derives an OTP from the visual challenge data and displays the OTP to the PSU. - 'PUSH_OTP': An OTP is pushed to a dedicated authentication APP and displayed to the PSU. - 'SMTP_OTP': An OTP is sent via email to the PSU.

authenticationVersion

string

Depending on the "authenticationType".
This version can be used by differentiating authentication tools used within performing OTP generation in the same authentication type.
This version can be referred to in the ASPSP?s documentation.

authenticationMethod

string

An identification provided by the ASPSP for the later identification of the authentication method selection.

name

string

This is the name of the authentication method defined by the PSU in the Online Banking frontend of the ASPSP.
Alternatively this could be a description provided by the ASPSP like "SMS OTP on phone +49160 xxxxx 28".
This name shall be used by the TPP when presenting a list of authentication methods to the PSU, if available.

explanation

string

Detailed information about the SCA method for the PSU.

chosenScaMethod

object

authenticationType

string

authenticationVersion

string

authenticationMethod

string

An identification provided by the ASPSP for the later identification of the authentication method selection.

name

string

explanation

string

Detailed information about the SCA method for the PSU.

_links

object

scaOAuth

object

startAuthorisationWithPsuIdentification

object

self

object

status

object

scaStatus

object

psuMessage

string

Text to be displayed to the PSU

Headers

object

X-Request-ID

uuid

ID of the request, unique to the call, as determined by the initiating party.

ASPSP-SCA-Approach

string

This data element must be contained, if the SCA Approach is already fixed.
Possible values are

DECOUPLED
REDIRECT
The OAuth SCA approach will be subsumed by REDIRECT.

Location

uri

URI where the client can view and accept consent. In case of errron will be returned redirect uri with error and error description

Examples:

success example with Location:

https://customerconsent.tbcbank.ge/loginappsandbox/session?sessionid=219d20e1-a34e-4608-89bc-0d55c66dd576
error example:

https://tempuri.org/callback?error=server_error&error_description=The authorization server encountered an unexpected condition that&state=e09bd498-262d-41be-8744-6a706ab3426a

Language

URL


xxxxxxxxxx
1
curl --request POST \
2
     --url https://test-api.tbcbank.ge/xs2a-sandbox/v1/payments/aspsp \
3
     --header 'accept: application/json' \
4
     --header 'content-type: application/json'

Click Try It! to start a request and see the response here! Or choose an example:

application/json

application/problem+json

201Created

400BadRequest

500Server Error