Payments Service Idempotency

Idempotency is a crucial concept in payment processing systems to ensure that operations like fund transfers are not accidentally performed more than once. This is particularly important in scenarios where network issues, retries, or other uncertainties might lead to the same operation being requested multiple times. In the context of the LHV Connect API, idempotency helps in avoiding duplicate payments when the same request is inadvertently submitted more than once.

Idempotency and the PAIN.001 File

For the Payments service in LHV Connect, idempotency is managed using the MsgId (Message Identification) field in the PAIN.001 XML file. The PAIN.001 file is a standardized format used for initiating credit transfer payments. Here's how it works:

• MsgId Field: The MsgId field is a unique identifier for each payment instruction. When a payment request is submitted, the system records the MsgId. If a subsequent request is made with the same MsgId, the system recognizes it as a duplicate and ignores the new request, ensuring that the payment is not processed more than once.

• Uniqueness of MsgId: It is critical that the MsgId is unique for each new payment request. Reusing the same MsgId across different requests will trigger the idempotency check, causing the system to reject the duplicate request. Therefore, careful management of MsgId values is essential for avoiding unintentional rejections or processing errors.

• Practical Example: Suppose a payment initiation request is sent with a MsgId of PAY-12345. If the payment process needs to be retried due to a timeout or any other issue, resending the request with the same MsgId (PAY-12345) will not result in a duplicate payment. The system will recognize this MsgId and ensure that only one payment is executed.

However, it does not prevent the processing of payments that have similar amounts, payment details, or other fields, as long as each request has a unique MsgId. This means that two payment requests with identical amounts, recipients, and dates can still be processed separately if their MsgId values differ. Therefore, while idempotency protects against accidental re-submission of the same transaction, it does not prevent intentional or unintentional creation of similar but distinct payments.

Sample

Sample of related PAIN.001 request and response where uniqueness check finds a duplicate message:

-- Check is done with MsgId = UNIQUE-1001 field
<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03">
    <CstmrCdtTrfInitn>
        <GrpHdr>
            <MsgId>PAY-12345</MsgId>
            <CreDtTm>2024-08-21T10:00:00</CreDtTm>
            <NbOfTxs>1</NbOfTxs>
            <CtrlSum>1000.00</CtrlSum>
            <InitgPty>
                <Nm>Sample Company</Nm>
            </InitgPty>
        </GrpHdr>
        <PmtInf>
            <PmtInfId>PAYMENT-001</PmtInfId>
            <PmtMtd>TRF</PmtMtd>
            <BtchBookg>false</BtchBookg>
            <NbOfTxs>1</NbOfTxs>
            <CtrlSum>1000.00</CtrlSum>
            ...
            
-- Related Response message
<?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>3000023259</MsgId>
            <CreDtTm>2024-08-21T10:00:00.409+01:00</CreDtTm>
            <InitgPty>
                <Id>
                    <OrgId>
                        <BICOrBEI>LHVBGB2LXXX</BICOrBEI>
                    </OrgId>
                </Id>
            </InitgPty>
        </GrpHdr>
        <OrgnlGrpInfAndSts>
            <OrgnlMsgId>PAY-12345</OrgnlMsgId>
            <OrgnlMsgNmId>pain.001.001.03</OrgnlMsgNmId>
            <GrpSts>RJCT</GrpSts>
            <StsRsnInf>
                <Rsn>
                    <Cd>NARR</Cd>
                </Rsn>
                <AddtlInf>Duplicate message.</AddtlInf>
            </StsRsnInf>
        </OrgnlGrpInfAndSts>
    </CstmrPmtStsRpt>
</Document>

Summary

Idempotency in the Payments service of LHV Connect is effectively managed through the MsgId field in the PAIN.001 file. This ensures that payment requests are processed exactly once, even if they are submitted multiple times, thereby safeguarding against duplicate transactions and ensuring the reliability of the payment process.