Overview
Purpose
The Payment Journey covers creation, retrieval, authorisation, status and eligible cancellation of supported payments.
Payment creation does not mean that a payment has been fully authorised, processed or settled. It creates a payment resource and returns its status. Use the returned links and status reports to determine the next step.
Use the same SMBC institution endpoint throughout the payment lifecycle. A payment, its authorisation resources and any signing basket containing it cannot be used through another institution endpoint.
Before creating a payment
Submit a supported payment product and valid ISO 20022 pain.001 message using a debtor account available to the PSU for payment initiation. Security and Access define the PISP and certificate requirements. Consents and the operation definition identify the applicable consent requirements. Getting Started and Technical Reference define institution selection and resource continuity.
Where signing is required by the operation, use the operation-specific profile in the Payments API. Do not assume that every state-changing operation uses the same signing profile.
Supported payment products
The supported payment products are:
- pain.001-sepa-credit-transfers;
- pain.001-internal-transfers;
- pain.001-swift-transfers;
- pain.001-chaps-payments; and
- pain.001-faster-payments.
Product availability may differ by SMBC institution. Technical Reference lists the supported product and message-version combinations, and the Payments API and SMBC ISO 20022 schema materials remain authoritative for field-level schemas, validation and product-specific restrictions.
Create a payment
Call: POST /payments/{payment-product}
The request body must contain a valid ISO 20022 pain.001 payment initiation message for the selected payment product.
A successful request creates a payment resource and returns its current status and available links as defined in the Payments API. Use the returned paymentId as an opaque API identifier in later requests. See Resource Identifiers in Technical Reference.
Every payment requires at least one customer authorisation before processing can complete. Most payments require two authorisations. No payment requires more than two authorisations. Use the returned links and payment status to determine the next action.
Payment resource and bulk structure
Each accepted pain.001 payment initiation creates one payment resource and returns one paymentId. The paymentId identifies the complete payment resource and may represent a payment with one credit transfer or a bulk of credit transfers.
Each pain.001 submitted through the API must contain exactly one PmtInf. That PmtInf has a one-to-one relationship with the resulting paymentId.
For a SEPA bulk payment, the single PmtInf may contain multiple CdtTrfTxInf credit-transfer instructions. The individual credit transfers may have separate statuses and reason information in the pain.002 status report, but they remain part of the same payment resource.
Payment authorisation, cancellation and retrieval operations apply to the Payment ID as a whole. Do not construct a Payment ID for an individual CdtTrfTxInf.
Requested execution date and payment expiry
The payment initiation message must contain a valid Requested Execution Date where required by the selected payment product.
If the requested execution date is in the past, or the payment is received after the applicable cut-off, SMBC rolls the payment forward to the earliest available business date. The adjusted date does not require the TPP to create a replacement Payment ID.
A payment that remains in PATC expires 90 days after creation if the required customer authorisations have not been completed. An expired payment is no longer available for authorisation or cancellation, and its status is reported as RJCT. Create a new payment only if the customer decides to submit the instruction again.
Retrieve payment details
Call: GET /payments/{payment-product}/{paymentId}
This operation retrieves the original accepted payment initiation. Use the same payment-product and paymentId returned when the resource was created. Requests to this endpoint must specify Accept: application/xml. See Content Types in Technical Reference for the response format.
Retrieve payment status
Call: GET /payments/{payment-product}/{paymentId}/status
The payment status report is the source for the current payment outcome and next available action. Do not rely only on the payment-creation response to determine whether a payment has been fully authorised, processed or cancelled.
The response is an ISO 20022 pain.002 Payment Status Report. Requests to this endpoint must specify Accept: application/xml.
Payment status determines the actions available for the payment. See Payment Status Guide for the main SMBC journey statuses and corresponding TPP actions. The Payments API remains authoritative for the complete schema and operation-level response definitions.
Verification of Payee
Verification of Payee applies to SEPA credit transfers submitted using:
POST /payments/pain.001-sepa-credit-transfers
A VoP check is required for each credit transfer where the debtor account is held with an SMBC institution in scope for VoP. London is excluded from VoP checks.
For XS2A API payments, the result is made available at credit-transfer level in the pain.002 payment status report while the payment remains pending authorisation. Retrieve the status and make the result available to the PSU before starting authorisation.
The following result indicators may be returned:
- In progress: RECI, with additional information indicating that Verification of Payee is in progress. This is a temporary result and will progress to a completed VoP outcome. Retrieve payment status using controlled status retrieval until a completed outcome is returned;
- Match: no VoP status reason code is returned;
- Close match: CMTC, with additional information that may contain the matched name returned by the responding PSP;
- No match: NMTC, with additional information such as VoP No Match;
- Not applicable or not possible: NOAP, with additional information such as Creditor agent not applicable for VoP or VoP Not Possible; and
- Service unavailable or technical failure: NOAP, with additional information such as VoP Service Unavailable.
VoP processing is subject to a timeout. If no completed match result is obtained within that period, the payment status report returns the applicable completed NOAP outcome and associated additional information. RECI is not a final VoP result.
The TPP must not start payment authorisation while the applicable VoP result remains RECI. Retrieve the payment status until the completed VoP outcome is available, then make that outcome available to the PSU before starting authorisation.
Where the same reason code is used for more than one scenario, use the associated additional information to interpret and present the result.
A result that is not a match does not automatically reject an XS2A API payment. The payment remains pending authorisation so that the PSU and TPP can decide whether to proceed, cancel or resubmit with different details.
Start authorisation
Call: POST /payments/{payment-product}/{paymentId}/authorisations
This operation starts SCA for an existing payment. In normal use, authorisation is started while the payment is in PATC. Where Verification of Payee applies, the authorisation request will be blocked with STATUS_INVALID and the SCA journey will not start while any applicable VoP result remains RECI. Authorisation may be started only after all applicable VoP results are complete.
Use the PSU and redirect context defined in the Payments API. PSU-ID, PSU-Device-ID and PSU-IP-Address are mandatory when starting an SCA journey. If the authorisation resource is created, redirect the PSU’s browser to the URL returned in the scaRedirect link. The PSU completes the SCA challenge using the PSU’s mobile device and the SMBC Digital mobile application.
After successful or unsuccessful SCA, the PSU is redirected to the supplied TPP-Redirect-URI. The redirect does not contain the SCA result. If the TPP included an optional state parameter, that value is preserved. Retrieve the authorisation status and then the payment status to determine the outcome and next action.
See Concurrent attempts in Authorisation Rules before starting another attempt.
Check authorisation status
Call: GET /payments/{payment-product}/{paymentId}/authorisations/{authorisationId}
This operation retrieves the SCA status of the authorisation resource. After the PSU completes SCA, retrieve payment status to determine the overall lifecycle state. A finalised authorisation SCA does not necessarily mean that every authorisation required for the payment is complete.
Cancel a payment
Call: DELETE /payments/{payment-product}/{paymentId}
This operation cancels an existing payment where its current status permits cancellation. A successful request returns 204 No Content. Retrieve payment status where confirmation of the resulting lifecycle state is required. See Payment Status Guide for status interpretation.
Payment journey errors
The Payments API defines the complete operation-specific HTTP statuses, public error codes and response structures.
Payment journey errors and TPP actions
Error
PRODUCT_UNKNOWN
Meaning
The requested payment product is not recognised or is not supported for the selected institution.
TPP action
Use a product supported for that institution.
Error
PAYMENT_FAILED
Meaning
Payment initiation could not be accepted after payment validation.
TPP action
Correct the request using the Payments API and applicable ISO 20022 schema requirements.
Error
STATUS_INVALID
Meaning
The requested lifecycle action is not permitted in the payment's current status.
TPP action
Retrieve payment status and follow the next available action.
Error
RESOURCE_UNKNOWN
Meaning
The requested payment, authorisation or related resource is not recognised or is not available in the request context.
TPP action
Verify the payment-product, identifiers, Consent ID and institution endpoint.
For role, certificate and signing failures, see Security and Access. For consent failures, see Consents. For common error and correlation principles, see Technical Reference.
The Payments API is authoritative for operation-level headers, schemas, signatures, examples and complete responses.
Authorisation rules
Purpose
Payment creation and authorisation are separate. SMBC applies the corporate customer's existing approval rules when a PSU attempts to approve a created payment.
Required authorisations
Every payment requires at least one authorisation. Most payments require a second authorisation, depending on the corporate customer's configuration and approval rules. No payment requires more than two authorisations.
A second authorisation, where required, is independent of the first and may be completed through an individual payment-authorisation journey or a signing basket. A signing basket may apply one authorisation to one or more eligible payments.
Separation of duty
The PSU who created a payment cannot perform its first authorisation.
If a second authorisation is required, the creator may be eligible to perform it, depending on the corporate customer's approval rules. The same PSU cannot perform both authorisations for the same payment.
Signatory groups
Where signatory-group rules apply, PSUs may be assigned to different groups. A payment requiring two authorisations may need approval by PSUs from different groups.
The API does not expose the customer's full signatory configuration. Rely on the returned authorisation status, payment status and errors to determine whether an attempted authorisation was accepted.
Approval limits
A PSU cannot authorise a payment above that PSU's applicable approval limit. Limits may differ by payment category and are not exposed by the API.
For signing baskets, approval is assessed against each payment, not only the combined basket value.
Concurrent attempts
Only one authorisation attempt may be active for a payment. A new attempt may begin only after the earlier attempt is no longer active.
Payment and SCA status
An authorisation SCA status describes one SCA journey. Payment status describes the overall lifecycle of the payment.
After SCA, retrieve payment status to determine the next action. A finalised authorisation SCA does not necessarily mean that every required authorisation is complete. See Payment Status Guide.
VoP and authorisation
Where Verification of Payee applies, make the result available to the PSU before authorisation. See Verification of Payee in Payment Journey for scope, result indicators and the PSU decision path.
Signing baskets
A signing basket contributes one authorisation to each included payment. It does not override the separation-of-duty, signatory-group, approval-limit or other eligibility rules in this section. See Signing Baskets for basket-specific behaviour.
API references
The Payments API is authoritative for operation-level endpoints, headers, signing requirements, schemas, errors and examples.
Signing baskets
Purpose
A signing basket allows one PSU to authorise one or more existing payments through a single SCA journey.
It groups payment authorisations but does not create or change the payments, alter their required number of authorisations or override the corporate customer's approval rules.
One successfully completed basket SCA contributes one authorisation to each included payment. Eligibility is evaluated separately for every payment under Authorisation Rules.
Supported operations
SMBC supports:
- POST /signing-baskets — creates a signing basket and starts its SCA journey; and
- GET /signing-baskets/{basketId} — retrieves the included Payment IDs together with the basket’s current SCA status and basket transaction status.
Creating a basket starts SCA immediately. No separate basket-authorisation, authorisation-list, authorisation-status or basket-deletion operation is supported.
The signing-basket operations in the Payments API Reference are authoritative for operation-level headers, schemas, links, errors and examples.
Eligibility
A signing basket must contain at least one Payment ID. The signing-basket operations in the Payments API Reference define the maximum number of Payment IDs that may be included.
Every included payment must:
- belong to the selected SMBC institution;
- be in PATC status and require another authorisation;
- be accessible in the request context and available to the PSU for authorisation;
- satisfy the corporate approval rules in Authorisation Rules; and
- have no active individual or basket authorisation attempt.
A basket may contain payments with different debtor accounts, corporate customers or legal entities, products, currencies, ISO 20022 versions and numbers of previously completed authorisations, provided the PSU is eligible to supply the next authorisation for every payment.
All included payments must belong to the same SMBC institution. Do not combine Payment IDs created through different institution endpoints.
Create the basket
Call: POST /signing-baskets
Supply the Payment IDs to be authorised.
Create the basket through the selected SMBC institution endpoint to which all included Payment IDs belong, using a valid authorised Consent ID, the PSU and redirect context, and the operation-specific signing requirements defined in the signing-basket operations in the Payments API Reference.
A successful response creates the basket, starts SCA and returns the basket ID and redirect link. Retain the basket ID and redirect the PSU.
Atomic creation
Creation is atomic. If any supplied Payment ID fails the eligibility rules in Eligibility, the complete request is rejected; no basket is created and no subset is accepted.
A payment cannot be included in a new basket while another individual or basket authorisation attempt is active. See Concurrent attempts in Authorisation Rules.
Complete SCA
Redirect the PSU’s browser to the URL returned in the scaRedirect link. The PSU completes the SCA challenge using the PSU’s mobile device and the SMBC Digital mobile application.
After successful or unsuccessful SCA, the PSU is returned to the supplied TPP-Redirect-URI. The return redirect does not contain the SCA result. If the TPP included an optional state parameter, SMBC preserves it.
Retrieve the basket using: GET /signing-baskets/{basketId}
The response returns the included Payment IDs together with the basket’s scaStatus and transactionStatus.
The basket transaction status has the following meaning:
- PATC: the basket has been created but has not been successfully approved;
- ACTC: the basket authorisation was successful; and
- RJCT: the basket authorisation was unsuccessful, including where the PSU cancelled the SCA journey, did not complete it or SCA failed.
The scaStatus describes the outcome of the basket SCA journey. The transactionStatus describes the outcome of the basket authorisation. Neither status represents the current lifecycle status of the individual payments included in the basket.
Effect on payments
A basket transactionStatus of ACTC means that the basket authorisation was successful and one authorisation was applied to each included payment. It does not confirm that every payment has received all required authorisations.
An included payment may remain in PATC where another authorisation is required. Retrieve the status of every included payment separately. The individual payment status determines the payment’s current lifecycle state and next available action.
Further authorisation
If an included payment still requires authorisation, another eligible PSU may use an individual journey or another eligible signing basket. See Authorisation Rules.
Consent requirements
Consent-ID is mandatory on POST /signing-baskets and GET /signing-baskets/{basketId}.
Use a valid authorised Consent ID that provides access to the included payment resources. The Consent ID must belong to the requesting TPP and institution, relate to the requesting PSU and provide payment-authorisation access to every included payment.
See Consents for the general consent lifecycle.
Uncompleted SCA
SMBC does not provide an operation to delete or cancel a signing basket.
If the PSU declines or does not complete SCA, no basket authorisation is applied. An unsuccessful basket SCA does not cancel the underlying payments. See Payment Journey for payment cancellation.
Basket errors
The signing-basket operations in the Payments API Reference define the complete operation-specific response structures.
Signing-basket errors and TPP actions
Error
FORMAT_ERROR
Meaning
The request is malformed, or a Payment ID is unknown, inaccessible or invalid for the request context.
TPP action
Review every Payment ID and correct the complete request before retrying.
Error
RESOURCE_UNKNOWN
Meaning
The Basket ID does not identify a basket available in the request context.
TPP action
Verify the Basket ID, Consent ID, TPP identity and institution endpoint.
Error
STATUS_INVALID
Meaning
One or more payments are not in an eligible lifecycle state or are involved in another active authorisation attempt.
TPP action
Retrieve the applicable payment or basket status and submit a new request only when every payment is eligible.
Funds confirmation
Funds confirmation allows an authorised PISP to request confirmation of whether sufficient funds are available on an eligible account for a specified amount. It does not reserve funds, create a payment or guarantee that the same amount will remain available for a later payment.
Call: POST /funds-confirmations
Use the same SMBC institution endpoint through which the applicable consent was created. Supply a valid authorised Consent ID and an account available to the PSU for the funds-confirmation operation.
The Payments API Reference defines the required headers, request body, response structure, signing requirements and operation-specific errors.
A successful response returns the funds-availability result defined in the Payments API Reference. Treat the response as a confirmation for that request only. It does not create a payment resource or Payment ID.
Payment status guide
Purpose
A payment status describes the current lifecycle state of a payment or an individual transaction within it.
Retrieve the current status using:
GET /payments/{payment-product}/{paymentId}/status
The response is an ISO 20022 pain.002 Payment Status Report. Use it to determine the current outcome and next available action.
This section explains the main SMBC payment journey statuses and corresponding TPP actions. The Payments API remains authoritative for the complete schema and operation-level response definitions.
Status types
The status types used during a payment journey are not interchangeable:
- HTTP status describes whether an individual API request was processed successfully. It does not establish that the payment is fully authorised or processed.
- Individual-authorisation SCA status describes one payment-authorisation journey. A finalised status does not necessarily mean that all required authorisations are complete.
- Signing-basket SCA status and basket transaction status describe the basket SCA journey and its authorisation outcome. A basket transactionStatus of ACTC does not confirm that every included payment has received all required authorisations. Retrieve every included payment’s status separately.
- Transaction status describes the lifecycle of an individual transaction. The authoritative field is TxInfAndSts/TxSts.
Read the pain.002 report
The pain.002 version corresponds to the pain.001 version used to create the payment. See Payment Products in Technical Reference.
Use the XML namespace to identify the returned version. Interpret TxInfAndSts/TxSts together with associated reason and date information where present.
Single and bulk payments
For a single-credit-transfer payment, use its TxInfAndSts/TxSts value as the current lifecycle status.
A bulk payment contains one PmtInf and multiple CdtTrfTxInf instructions under one Payment ID. Process every TxInfAndSts entry in the pain.002 separately because different credit transfers may have different statuses and reason information.
Do not calculate or publish a single aggregate status for a mixed-status bulk unless one is explicitly returned by the API. Payment authorisation, cancellation and retrieval remain operations on the complete Payment ID; an individual credit transfer within the payment cannot be authorised or cancelled through a separate API resource.
Where the complete request is rejected at group level, use the returned group status and associated reason.
Status action matrix
The matrix explains the lifecycle meaning of the main SMBC journey statuses. If a different valid ISO 20022 status is returned, interpret it using the Payments API, the associated reason information and the specific response context.
Payment authorisation and cancellation remain payment-resource operations. For a mixed-status bulk, follow the operation-level behaviour returned by the Payments API rather than inferring that an individual transaction can be authorised or cancelled separately.
Transaction-status meanings and TPP actions
TxSts
PATC
SMBC meaning
The transaction has been accepted as technically correct but still requires one or more customer authorisations.
Final
No
Further authorisation required
Yes, where the PSU is eligible and no attempt is active.
Cancel permitted
Yes
Further status retrieval
Yes, after authorisation, cancellation or another relevant lifecycle event.
Next action
Review VoP where applicable, complete the required authorisation or cancel the payment.
TxSts
PDNG
SMBC meaning
All required customer authorisations are complete, and the transaction is being processed by SMBC.
Final
No
Further authorisation required
No
Cancel permitted
No
Further status retrieval
Yes, using controlled status retrieval while processing remains incomplete.
Next action
Allow processing to continue; do not authorise, cancel or create a duplicate payment.
TxSts
RJCT
SMBC meaning
The transaction has been cancelled, expired or rejected and will not continue for processing.
Final
Yes
Further authorisation required
No
Cancel permitted
No
Further status retrieval
No routine polling required.
Next action
Read the reason information, stop lifecycle actions and do not resubmit automatically.
TxSts
ACCP
SMBC meaning
Processing by SMBC is complete.
Final
Yes
Further authorisation required
No
Cancel permitted
No
Further status retrieval
No routine polling required.
Next action
Treat SMBC processing as complete; do not infer receipt of funds by the beneficiary bank.
PATC
PATC is an intermediate payment status: the payment has passed the applicable technical validation but has not completed every required customer authorisation.
If one authorisation has finalised but the payment remains in PATC, another eligible PSU may need to authorise it.
Where Verification of Payee applies, the pain.002 status report may initially contain RECI while the Verification of Payee check is in progress. RECI is temporary and progresses to a completed Verification of Payee outcome. Retrieve payment status using controlled status retrieval until the completed outcome is returned.
Make the completed Verification of Payee result available to the PSU before the next authorisation decision. Do not start the next authorisation while the applicable Verification of Payee result remains RECI.
Do not create another payment merely because the existing payment remains in PATC.
PDNG
PDNG is an intermediate status. All required customer authorisations are complete and the transaction is being processed by SMBC.
A future-dated transaction may remain in PDNG while processing waits for the applicable execution date.
The length of time in PDNG does not itself prove rejection or a service problem.
Use controlled status retrieval and do not create a replacement payment solely because the status has not changed.
RJCT
RJCT is terminal. The transaction will not continue for processing in its current form because it was cancelled, expired before all required authorisations were completed, or was rejected or cancelled during processing.
Read the associated reason information, present the outcome accurately and stop lifecycle actions for the existing Payment ID.
Create a new payment only if the customer decides to submit another instruction; do not resubmit automatically.
ACCP
ACCP is terminal in the SMBC XS2A implementation and means that processing by SMBC is complete.
It does not confirm that the beneficiary received the funds, that the beneficiary bank credited the beneficiary account or that settlement outside SMBC completed.
Use any settlement or date information only according to the applicable pain.002 field.
Status reasons and VoP
Interpret reason information in the context of its accompanying transaction status. A reason code does not always mean that the transaction was rejected.
For an applicable SEPA credit transfer, VoP reason information may be present while TxInfAndSts/TxSts remains PATC.
These values inform the PSU's decision before authorisation; they do not by themselves mean RJCT. See Verification of Payee in Payment Journey for scope, result indicators and PSU presentation.
When TxInfAndSts/TxSts is RJCT, use the associated reason information to identify why the transaction will not continue.
Do not replace a specific returned reason with a generic payment-failed message where more precise public information is available.
Cancellation and status retrieval
Cancellation is available only where permitted by the current payment status. See Payment Journey for the cancellation operation and this guide for the resulting lifecycle interpretation.
Use controlled status retrieval:
- after creating a payment;
- while an applicable Verification of Payee result remains RECI, until a completed outcome is returned;
- after an individual-authorisation SCA journey;
- after a signing-basket SCA journey;
- while a transaction remains in PDNG;
- after cancellation where confirmation is required; or
- after a previous status request could not be completed.
Controlled status retrieval means checking status when needed to determine the next action without continuous or overlapping requests.
Do not create concurrent polling loops, interpret a temporary API error as RJCT, create a duplicate payment merely because a transaction remains in PDNG, or continue routine polling after RJCT or ACCP.
Requests are subject to the per-TPP rate limits defined in Technical Reference. If the API returns HTTP 429 with TOO_MANY_REQUESTS, reduce the request rate before retrying.
Related guidance
This section provides guidance for PATC, PDNG, RJCT and ACCP meanings, lifecycle classification, permitted actions, controlled status retrieval and the distinction between transaction and SCA status.
Information remains authoritative elsewhere as follows:
- payment creation, VoP applicability and the end-to-end journey — Payment Journey;
- PSU eligibility, separation of duty, signatory groups and approval limits — Authorisation Rules;
- basket creation and SCA — Signing Baskets;
- supported pain.001 and pain.002 versions — Technical Reference; and
- schemas, namespaces, structured fields, examples and complete operation-specific responses — Payments API.