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
[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>
[0..1]
++++Reason
<Rsn>
[1..1]
+++++Code
<Cd>
If Transaction Status is ACWC or RJCT, then ‘NARR’.
[0..n]
++++AdditionalInformation
<AddtlInf>
[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
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
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
Was this helpful?