- 05 Jul 2022
- 5 Minutes To Read
-
Print
-
DarkLight
-
PDF
Payment Order Flow
- Updated On 05 Jul 2022
- 5 Minutes To Read
-
Print
-
DarkLight
-
PDF
The processing of the Payment Order is done in four stages: Initiate, Accept, Clear and Settle.
Initiate
The Payment Order is initiated by the Payment Service User via Payments API.
Accept
The Payment Order is validated and enriched with additional data, such as BIC code.
Clear
After checking if debtor has sufficient funds or that their deposit account is not blocked, the Payment Order is validated by debiting the debtor account.
Settle
The Payment Order is executed on the beneficiary side.
Whenever the beneficiary is within the same financial institution as debtor, the beneficiary account is credited and the Payment Order execution is completed. Whenever the beneficiary is in a different financial institution, an outgoing payment settlement is initiated via the CSM.
Rejected
If the payment is rejected in any stage of the payment flow the status is updated to rejected.
Payment status
Possible transaction statuses:
- RCVD (Received): Payment initiation has been received.
- ACTC (Accepted Technical Validation): Payment order has been accepted .
- ACSP (Accepted Settlement In Process): Outgoing payment order execution and Debit Transaction has been initiated.
- ACSC (Accepted Settlement Completed): Payment order completed
- RJCT (Rejected): Payment request has been rejected.
Settlement
In Mambu we deal with two different push payments:
- Intrabank
- Interbank
Intrabank
If intrabank, meaning that Mambu identifies that both clients are in the same financial institution, a transfer transaction is made from the originator to the account of the beneficiary. The paymentDetails
object of the transfer will include details of the payment request, including the end to end ID and scheme used, for example SEPA.
Interbank
If the payment is an interbank payment, meaning that originator and beneficiary are in different financial institutions then Mambu will initiate the scheme flow and generate the necessary accounting postings and generate the files for the specific payment, so for example in a outgoing SEPA payment, after Mambu receives the Payment request and identifies that is a SEPA CT payment then Mambu will generate a pacs.008 (Please refer to the section SEPA to get a better understanding of SEPA in Mambu)
Outgoing payment accounting posting:
Debit - Originator account
Credit - Channel GL account
Incoming payment accounting posting:
Debit - Channel GL account
Credit - Beneficiary account
initiatePayment
Creates a payment initiation request.
Action: POST
Endpoint: /v1/payments/
{
"debtorAccount": {
"identification": {},
"currency": "EUR"
},
"debtorName": "John Doe",
"debtorAddress": {
"street": "Karl-Liebknecht-Str. 5",
"buildingNumber": "5234",
"city": "Berlin",
"postalCode": "10178",
"countryCode": "DE"
},
"instructedAmount": {
"currency": "EUR",
"amount": "500"
},
"creditorAccount": {
"identification": {},
"currency": "EUR"
},
"creditorAgent": {
"institutionIdentification": {}
},
"creditorName": "Merchant123",
"creditorAddress": {
"street": "Am Olympiapark 1",
"buildingNumber": "1",
"city": "Munchen",
"postalCode": "80809",
"countryCode": "DE"
}
}
Response codes
Code | Meaning | Description |
---|---|---|
200 | OK | Payment Initiation Details were correctly found. |
400 | Bad Request | Validation error occurred. This code will cover malformed syntax in request or incorrect data in payload |
405 | Method Not Allowed | This code is only sent when the HTTP method (PUT, POST, DELETE, GET etc.) is not supported on a specific endpoint. It has nothing to do with the consent, payment or account information data model. |
406 | Not Acceptable | A media type which the serves does not support has been supplied. |
500 | Internal Server Error | Internal server error occurred |
503 | Service Unavailable | The server is currently unavailable. Generally, this is a temporary state |
Payment Details
The endpoint returns payment information including:
- Status
- Payment execution time
- BIC information
- Debtor and Creditor IBAN
- Currency
- Amount
- Debtor and Creditor name
- Payment Purpose
- Remittance information
Action: GET
Endpoint: /v1/payments/{paymentId}
Parameters
Name | Value |
---|---|
paymentID | The payment ID in MAMBU |
Sample response body
200 - OK
{
"transactionStatus": "ACSC",
"lastStatusUpdateTimestamp": "2020-01-08T11:05:37Z",
"debtorAccount": {
"identification": {
"iban": "RO71BTRLV67M9G4XIEE3IEJ5D2"
},
"currency": "EUR"
},
"debtorAgent": {
"institutionIdentification": {
"bicfi": "BTRLRO22XXX"
}
},
"debtorName": "John Doe",
"instructedAmount": {
"currency": "EUR",
"amount": "50"
},
"creditorAccount": {
"identification": {
"iban": "RO28INGBT26QJ2VR5QYEE2COV"
},
"currency": "EUR"
},
"creditorAgent": {
"institutionIdentification": {
"bicfi": "INGBROBUXXX"
}
},
"creditorName": "Robert",
"purposeCode": "SALR",
"remittanceInformationUnstructured": "Remittance information up to 140 characters"
}
400 - Bad request
{
"tppMessages": [
{
"category": "ERROR",
"code": "SERVICE_INVALID",
"path": "paymentId",
"text": "Unable to find payment details for payment 2809684547d49208b0e05d501e15b5f"
}
]
}
405 - Method Not Allowed
{
"tppMessages": [
{
"category": "ERROR",
"code": "SERVICE_INVALID",
"text": "There was an error processing your request. It has been logged (ID a449ea6319107e42)."
}
406 - Not acceptable
{
"tppMessages": [
{
"category": "ERROR",
"code": "SERVICE_INVALID",
"text": "There was an error processing your request. It has been logged (ID a449ea6319107e42)."
}
500 - Internal Server Error
{
"tppMessages": [
{
"category": "ERROR",
"code": "SERVICE_INVALID",
"text": "There was an error processing your request. It has been logged (ID a449ea6319107e42)."
}
Payment Events
The Mambu Streaming API allows tenants to receive payments data in a different way than pulling it from the payments API, instead you can opt to receive notifications and payment information on the different stages of a payment as events which are pushed to your own sytems in real time:
To be able to receive these events, the following steps are required:
Create an “Event template” for an action (e.g Payment Settled)
Before saving, choose what information you would likle to receive with these events by selecting the appropriate placeholders. At the moment the placeholders available for payments are:
Creditor
- Creditor Account Currency
- Creditor Account IBAN
- Creditor Account Id
- Creditor Account Identification
- Creditor Account Scheme
- Creditor Address - Building Number
- Creditor Address - City
- Creditor Address - Country Code
- Creditor Address - Line1
- Creditor Address - Line2
- Creditor Address - Postal Code
- Creditor Address - Street
- Creditor BICFI
- Creditor Name
Debtor
- Debtor Account Currency
- Debtor Account IBAN
- Debtor Account Id
- Debtor Account Identification
- Debtor Account Scheme
- Debtor Address - Building Number
- Debtor Address - City
- Debtor Address - Country Code
- Debtor Address - Line1
- Debtor Address - Line2
- Debtor Address - Postal Code
- Debtor Address - Street
- Debtor BICFI
- Debtor Name
Payment
- End To End Identification
- Error Description
- Errors
- Instructed Amount
- Instructed Amount Currency
- Instructed Transaction ID
- Instruction Identification
- Message Identification
- Purpose Code
- Remittance Issuer
- Remittance Reference
- Remittance Reference Type
- Remittance Unstructured
- Requested Execution Date
- Requested Execution Time
- Settlement Date
- Status
- Transaction ID
- Ultimate Creditor
- Ultimate Debtor
- Value Date
Create a subscription
With the topic generated in the “Event template” : mrn.event.demotenant.streamingapi.client_created
create a subscription : creating subscriptions
Consume the events
With the previous subscription you can consume the events: consuming events from a subscription
Once a client is created you can receive a notification message and consume it for any purposes (such as accounting).