pain.002.001.15 CustomerPaymentStatusReportV15

ISO 20022 pain Messages

Tell a prior party whether a customer instruction has been accepted, rejected, or remains pending.

Cedar Books submits a EUR 125.00 one-time setup-fee payment for Example Services, invoice INV-DEMO-101, requested for 2026-01-06. Fictional Cedar Bank returns DEMO-M002-001 at 2026-01-05T09:00:00Z, referencing DEMO-M001-001, DEMO-CT-BATCH-001, DEMO-CT-INSTR-001 and DEMO-CT-E2E-001. Group and transaction statuses are ACTC, representing technical acceptance in the existing example. Cedar Books continues tracking the later outcome. The January subscription collection is a different instruction and invoice, despite having the same EUR 125.00 amount.

The service's bilateral or multilateral agreement determines which reports, statuses, detail levels and delivery arrangements apply. The pain.002.001.15 base schema permits OrgnlPmtInfAndSts to be absent and permits repeated detail blocks when present. A bank profile can require more information. Base optionality does not mean a receiving application can complete its workflow without the references its contract needs.

The message can report credit-transfer, direct-debit and other customer instructions, but this worked file refers specifically to pain.001.001.13. It does not report the separate January subscription collection in pain.008.001.12. Equal EUR 125.00 amounts do not connect two obligations. Correlate by original message, payment-information and transaction references, then check the parties and purpose where available.

Use the status definition from the applicable code set and the profile's permitted usage; internal labels cannot redefine it. The stored XSD's external status types constrain text length rather than enumerate all accepted values. A string can therefore pass this XSD without being an allowed business status. The ACTC explanation here retains the existing technical-acceptance example; it does not supply a complete status-code dictionary.

The ISO catalogue's pain.002.001.15 availability is not evidence that a scheme requires V15. The inspected EPC 2025 customer-to-PSP profiles use pain.002.001.10. Use the actual service's message/version and current profile rather than combining a newer global schema with older profile cardinalities. No current CBPR+ deadline or inaccessible MyStandards rule is established by this lesson.

Use the existing Fields and XPath view for the local declarations, datatype restrictions and optional-ancestor context behind these values. A mapper should record which source instruction each report updates, which optional details its service requires and what to do when those details are absent. In this single-item example no mixed-result bulk aggregation, customer ledger mapping or service-specific enquiry message is demonstrated.

Test service rules as well as grammar. In the existing structural exercise, omitting the optional detail block can remain XSD-valid and a four-character unknown external status can also pass the base schema. Those results are warnings about validation scope, not permission to accept the unknown value in production. Validate the selected code release and profile, and route unsupported or inconsistent evidence through an agreed exception process.

Explore the complete Payment Life Cycle