Payment Initiation Response
Response
XML format (ISO 20022 Customer Payment Status Report pain.002)
The ISO 20022 Customer Payment Status Report (pain.002) message is sent to the client to inform about the status of a payment instruction sent via LHV Connect with Payment Initiation (pain.001) message.
Customer Payment Status Report refers to the original Payment Initiation message and provides positive, negative and pending status updates to original payments. There can be many Customer Payment Status Reports per one Payment Initiation message - typically if any of the transactions was not accepted right away for any reason.
Payment status codes and descriptions
Statuses are reported on group level for the whole payment instruction (GrpSts and PmtInfSts tags) and separately for each payment (TxSts tag). Group level statuses are reported only in the first payment response message after the initial request. Further responses (if any) shall not contain GrpSts and PmtInfSts tags - you must process the result of every payment entry separately.
Group level statuses (OrgnlGrpInfAndSts.GrpSts and OrgnlPmtInfAndSts.PmtInfSts):
RJCT β all payments in original pain.001 Payment Information block have been rejected.
PDNG - pending, payments are pending on human intervention. Typically, waiting for SCA in the Internet Bank.
PART β if some of the payments in original pain.001 Payment Information block have reached one of the accepted statuses (ACSC, ACSP, ACWC), but some also rejected, then status is partially accepted.
ACSP - all payments in original pain.001 have reached at least one of the accepted statuses (ACSC, ACSP, ACWC), but not debited yet
ACSC - all payments in original pain.001 are debited from clientβs account.
Single payment statuses (OrgnlPmtInfAndSts.TxInfAndSts.TxSts):
RJCT β rejected. Payment has been rejected (final status).
PDNG - pending. Payment is waiting for human intervention. Options: waiting for SCA in the Internet Bank or being reviewed by the Bank due to sanctions screening or manual corrections. More details below.
ACSP β accepted, settlement in process. Payment is being processed by the bank, it has not been debited from client account nor sent to clearing system. At least one more status update must follow (either accept or reject).
ACWC β accepted with change. Payment is being processed by the bank, it is not debited from client account. LHV has changed something about this payment. The reason for change is given in(3.25) tag. The changes are minor and do not harm the clientβs intention. At least one more status is sent about this payment (either accept or reject).
ACSC β accepted, settlement completed and payment has been debited from client account. ACSC is typically the final status. In rare occasions it can be followed by RJCT - then already debited payment is credited back to the payment account.
XML Schema Validation
One of the first steps when generating the response for the original pain.001 message is actually validating the content of the XML according to the XML Schema Definition - XSD.
Depending on what Customer submitted and the validation results also the response message structure might be different:
In all cases when there is some fatal error with the payment initiation the response will contain OrgnlGrpInfAndSts.GrpSts = RJCT value.
When there are basic XML structure issues or the XML does not meet the XSD requirements the response message does not contain OrgnlMsgId reference - it is provided only when the XML can be fully parsed.
Customer should always find the relation between the original Payment Initiation request and Response first using Message-Request-Id and Message-Response-Id as including OrgnlMsgId is not guaranteed.
Samples
In this case there was a syntax error in XML - CdtrAcct.Id.IBAN value was not in correct format.
Pending payments and human intervention
When payment receives PDNG status after ACSP status (payment is accepted by the customer or does not need SCA depening on the contract) it means that the payment needs human intervention and manual review. Depending on the case it can be a sanctions screening match or some other trigger that caused this. Direct communication with the customer might follow. When possible more details will be provided in the payment message narrative.
When the manual intervention case is resolved the payment will continue normal flow and get ACSC or RJCT status depending on the decision and conditions.
Payment rejection due to account balance or limits
By default, all payments will be rejected right away when there is not enough free balance or payments limits to execute the payment. Only on special agreement with the customer system will continue to try executing such payments:
Every day all payments sent 00:00 - 18:00 (Estonian time) and partially accepted will be rejected 18:00+5 minutes (if conditions are not met by this time).
All payments sent 18:00 β 00:00 (Estonian time) and partially accepted will be rejected 5 minutes after sending.
Message structure (pain.002.001.10/pain.002.001.03)
Response message version depends on the message used to initialize the original payment.
If payment is initialized with old pain.001.001.03, then old pain.002.001.03 is provided in response.
If payment is initialized with new pain.001.001.09 then new pain.002.001.10 is provided in response.
Pain.002 schema file: pain.002.001.10.xsd.
Note: Old pain.002.001.03 and upcoming version pain.002.001.10 are very similar. Differences are mentioned in "LHV Requirement" column.
Group Header β mandatory, occurs once. Set of characteristics shared by all individual payments included in the status report message. Original Group Information And Status β occurs once. Refers to original Payment Initiation Group Level information. Transaction Information And Status β optional and repetitive. Includes information about the original payment and its status.
Message root
<CstmrPmtStsRpt>
Group header
MULT. | MESSAGE ELEMENT | XML TAG | LHV Requirement |
---|---|---|---|
[1..1] | +GroupHeader | <GrpHdr> | |
[1..1] | ++MessageIdentification | <MsgId> | Unique message id created by LHV. |
[1..1] | ++CreationDateTime | <CreDtTm> | Creation date and time. |
[0..1] | ++InitiatingParty | <InitgPty> | |
[0..1] | +++Identification | <Id> | |
[0..1] | ++++OrganisationIdentification | <OrgId> | |
[0..1] | +++++AnyBIC | <AnyBIC> | LHVβs BIC. Note: In old version of pain.002.001.03 this field is named BIC |
[1..1] | +OriginalGroupInformationAndStatus | <OrgnlGrpInfAndSts> | |
[1..1] | ++OriginalMessageIdentification | <OrgnlMsgId> | Original pain.001.001.09 Group Level Message Id. |
[1..1] | ++OriginalMessageNameIdentification | <OrgnlMsgNmId> | Value βpain.001.001.09β. |
[0..1] | ++GroupStatus | <GrpSts> | Specifies the Group status of all payments in the original pain.001 message. Status codes explained above. |
[0..n] | ++StatusReasonInformation | <StsRsnInf> | |
[0..1] | +++Reason | <Rsn> | |
[1..1] | ++++Code | <Cd> | If Group Status is RJCT, then filled with βNARRβ. In this case, Additional Information is also filled. |
[0..n] | +++AdditionalInformation | <AddtlInf> | If Reason Code is filled with βNARRβ, error description is present here. See Group Level Errors. |
[0..n] | +OriginalPaymentInformationAndStatus | <OrgnlPmtInfAndSts> | |
[1..1] | ++OriginalPaymentInformationId | <OrgnlPmtInfId> | Original pain.001.001.09 Payment Information Id. |
[0..1] | ++PaymentInformationStatus | <PmtInfSts> | Specifies the Group status of one PmtInf block in the original pain.001 message. Status codes explained Status codes explained above. |
[0..n] | ++TransactionInformationAndStatus | <TxInfAndSts> | |
[0..1] | +++OriginalInstructionIdentification | <OrgnlInstrId> | Original payment order number. |
[0..1] | +++OriginalEndToEndId | <OrgnlEndToEndId> | Not used. |
[0..1] | +++TransactionStatus | <TxSts> | Payment status. Status codes explained above. |
[0..n] | +++StatusReasonInformation | <StsRsnInf> | |
[0..1] | +++OriginalTransactionReference | <OrgnlTxRef> | Payment scheme information |
[1..1] | ++++PaymentTypeInformation | <PmtTpInf> | |
[1..1] | +++++ServiceLevel | <SvcLvl> | |
[1..1] | ++++++Proprietary | <Prtry> | Payment scheme code - Code Set: Payment scheme. |
[0..1] | ++++Reason | <Rsn> | |
[1..1] | +++++Code | <Cd> | If Transaction Status is ACWC or RJCT, then βNARRβ. |
[0..n] | ++++AdditionalInformation | <AddtlInf> | If Reason Code is βNARRβ, then description or scheme reject code is given here. For Transaction Status βACWCβ, see Reason for Change; for Transaction Status βRJCTβ, see Transaction Level Errors. For payment scheme error codes see Code Set: Payment Scheme Reject Codes. |
[0..1] | +++AccountServicerReference | <AcctSvcrRef> | Unique payment ID assigned by the bank. |
[0..1] | +++OriginalTransactionReference | <OrgnlTxRef> | |
[0..1] | ++++Amount | <Amt> | |
[1..1] | +++++InstructedAmount | <InstdAmt Ccy="AAA"> | |
[0..1] | ++++RequestedExecutionDate | <ReqdExctnDt> | Execution date requested by client. |
[0..1] | ++++Debtor | <Dbtr> | |
[0..1] | +++++Pty | <Pty> | Note: In old version of pain.002.001.03 this element does not exist |
[0..1] | ++++++Name | <Nm> | Debtorβs name. |
[0..1] | ++++DebtorAccount | <DbtrAcct> | |
[1..1] | +++++Identification | <Id> | |
{Or | ++++++IBAN | <IBAN> | Debtorβs IBAN or Virtual IBAN. |
{Or | ++++++Other | <Othr> | Debtor's non-IBAN account number (for example, UK account number). |
Or}} | +++++++Identification | <Id> | Account number. |
[0..1] | ++++DebtorAgent | <DbtrAgt> | |
[1..1] | +++++FinancialInstitutionId | <FinInstnId> | |
[1..1] | ++++++BICFI | <BICFI> | LHVβs BIC. Note: In old version of pain.002.001.03 this field is named BIC |
[0..1] | ++++CreditorAgent | <CdtrAgt> | |
[1..1] | +++++FinancialInstitutionId | <FinInstnId> | |
[1..1] | ++++++BICFI | <BICFI> | Creditorβs bank BIC. Note: In old version of pain.002.001.03 this field is named BIC |
[0..1] | ++++Creditor | <Cdtr> | |
[0..1] | +++++Pty | <Pty> | Note: In old version of pain.002.001.03 this element does not exist |
[1..1] | ++++++Name | <Nm> | Creditorβs name. |
[0..1] | ++++CreditorAccount | <CdtrAcct> | |
[1..1] | +++++Identification | <Id> | |
[0..1] | ++++++IBAN | <IBAN> | Creditorβs IBAN. UK Faster Payments - used when also payment request contained IBAN. |
[0..1] | ++++++Other | <Othr> | |
[1..1] | +++++++Identification | <Id> | Creditorβs account number which is not IBAN. UK Faster Payments - used when also payment request contained sort code + domestic account nr. |
Error codes
Group level errors
GROUP STATUS | ADDITIONAL INFORMATION | DESCRIPTION |
---|---|---|
RJCT | Duplicate message. | Message with this id already exists. |
RJCT | Duplicate message. | Duplicate payment information block in file. |
RJCT | Uploading file failed. Faulty number of payments in file header. | Invalid Number Of Transactions in Header Level. |
RJCT | Uploading file failed. Faulty control sum in file header. | Invalid Control Sum in Header Level. |
RJCT | Uploading file failed. Faulty number of payments in Payment Information block. | Invalid Number Of Transactions in referenced Payment Information block. |
RJCT | Uploading file failed. Faulty control sum in Payment Information block. | Invalid Control Sum in referenced Payment Information block. |
RJCT | Uploading file failed. Faulty sender account [IBAN]. | At least one IBAN or Virtual IBAN does not exist. First bad number encountered is added to error message. |
RJCT | Corrupted payment file: [validation error description] | XML file doesnβt pass XSD validation. Reference to invalid value is given if possible. |
RJCT | No rights to debtorβs account. |
Transaction level errors
TRANSACTION STATUS | ADDITIONAL INFORMATION | DESCRIPTION |
---|---|---|
RJCT | Duplicate payment | |
RJCT | Account temporarily closed | |
RJCT | Account closed | |
RJCT | Creditor account is closed | |
RJCT | Reason not given | |
RJCT | Technical problem. Try again | |
RJCT | Invalid creditor address or name | |
RJCT | Incorrect account number | |
RJCT | Account number is not correct | |
RJCT | Invalid account number or sort code | |
RJCT | Creditor address is missing/not correct | |
RJCT | Invalid creditor name | |
RJCT | Missing or invalid reference | |
RJCT | Problem with amount. Contact bank | |
RJCT | Instant payment forbidden, try European payment | |
RJCT | Payment declined, try European payment | |
RJCT | Payment declined | |
RJCT | Payment declined. Regulatory reasons. Try European payment | |
RJCT | Reference number is invalid or returned for no reason, try European payment | |
RJCT | Other reason | |
RJCT | Reference number invalid. | |
RJCT | Cross-border payments from this account are prohibited. | |
RJCT | Invalid creditorβs name. | |
RJCT | Creditor's Correspondent BIC not valid. | |
RJCT | Invalid client account number / account not found. | |
RJCT | Payments from one Trader account to another are not allowed. | |
RJCT | Trader account. Not allowed currency. | |
RJCT | Description or reference number must be entered. | |
RJCT | Debtor's organisation identification code is faulty. | |
RJCT | Creditor's Bank BIC not valid. | |
RJCT | Creditor's organisation identification code is faulty. | |
RJCT | Creditor's account number not valid. | |
RJCT | Creditor's private person identification code is faulty. | |
RJCT | Insufficient daily limit available. | |
RJCT | Invalid currency. | |
RJCT | Payment to the same account. | |
RJCT | Payment to receiver account not allowed. | |
RJCT | Ultimate debtor's organisation identification code is faulty. | |
RJCT | Ultimate debtor's private person identification code is faulty. | |
RJCT | Insufficient monthly limit available. | |
RJCT | Correspondent Bank BIC not valid. | |
RJCT | Account and BIC country codes not matching. | |
RJCT | Account and BIC country codes not matching. Check the account number of the recipient and the BIC number of the recipient bank. | |
RJCT | Debtor's private person identification code is faulty. | |
RJCT | Insufficient funds available. | |
RJCT | Signature weight is less than 100%. | |
RJCT | Creditor account number is incorrect. IBAN is mandatory. | |
RJCT | Invalid payment order no. | |
RJCT | Other reason. | |
RJCT | Payment description is too long. Please use maximumcharacters. | |
RJCT | Please use Latin characters only. | |
RJCT | This BIC does not conform to the format. Enter the name and address of the creditorβs bank. Insert the creditorβs bank code (such as ABA or Fedwire) before the name of the creditorβs bank. | |
RJCT | Uploading file failed. Faulty sender account. | |
RJCT | Technical problem. Try again | |
RJCT | Requested by customer | |
RJCT | Payment declined. Regulatory reasons | |
RJCT | Incorrect creditorΒ΄s bank data | |
RJCT | Uploading file failed. Unparsable value in Instruction for Debtor Agent [InstrForDbtrAgt] | |
RJCT | RUB payment codes missing (INN, VO, KPP) | |
RJCT | Debtor's account not active. | Virtual IBAN exists, but is not active |
RJCT | Invalid debtor's name | Virtual IBAN holder name does not match with payment order (PmtInf.Dbtr.Nm) or debtor name missing if payment is from indirect agent's existing account. |
RJCT | Invalid return code | Invalid payment scheme return code is used |
RJCT | Original payment not received | Payment to be returned does not exist |
Last updated