Connect

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.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">
    <CstmrPmtStsRpt>
        <GrpHdr>
            <MsgId>1000001941</MsgId>
            <CreDtTm>2024-05-20T08:08:51.865+01:00</CreDtTm>
            <InitgPty>
                <Id>
                    <OrgId>
                        <BICOrBEI>LHVBGB2LXXX</BICOrBEI>
                    </OrgId>
                </Id>
            </InitgPty>
        </GrpHdr>
        <OrgnlGrpInfAndSts>
            <OrgnlMsgNmId>pain.001.001.03</OrgnlMsgNmId>
            <GrpSts>RJCT</GrpSts>
            <StsRsnInf>
                <Rsn>
                    <Cd>NARR</Cd>
                </Rsn>
                <AddtlInf>Corrupted payment file:
Line 72, column 35, cvc-pattern-valid: Value '32234523 232342' is not facet-valid</AddtlInf>
            </StsRsnInf>
        </OrgnlGrpInfAndSts>
    </CstmrPmtStsRpt>
</Document>

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.

      <TxInfAndSts>
        ....
        <TxSts>PDNG</TxSts>
        <StsRsnInf>
          <Rsn>
            <Cd>NARR</Cd>
          </Rsn>
          <AddtlInf>In manual review</AddtlInf>
        </StsRsnInf>

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

Error codes

Group level errors

Transaction level errors

Previouspain.001.001.03 formatNextSamples

Last updated