Use
pacs008 as the {format} path parameter when submitting this message type:
POST /v1/payout-origination/pacs008pacs.008.* as one of the supported payout origination formats. You must submit the full original ISO 20022 XML document as a single opaque payload. Do not split the message into API fields or convert it into another structure.
Meridian intake requirements
What Meridian means by full pacs.008
Meridian expects the complete business message content for the payment instruction you are submitting. That means you should preserve:- the original XML structure
- the version-specific namespace
- the element hierarchy
- the values and formatting used in the original message
pacs.008 fields into separate JSON properties.
High-level document structure
Apacs.008 message is an ISO 20022 customer credit transfer instruction. The exact variant depends on the message version you use, but the structure is typically organized like this:
Documentis the XML root elementFIToFICstmrCdtTrfcontains the credit transfer messageGrpHdrcontains message-level metadataCdtTrfTxInfcontains the payment transaction details
pacs.008 version and network rules, the document may include one or more transaction blocks and additional optional elements.
For Meridian Payout Origination, the submitted message must contain exactly one CdtTrfTxInf block. Messages with multiple transaction blocks are outside the documented contract for this API.
Common sections
The table below describes the sections most integrators will recognize in apacs.008 document. Exact child elements vary by schema version and implementation profile.
Settlement currency
TheCcy attribute on IntrBkSttlmAmt in your submitted message determines the payout currency and flows through to amounts.debit.currency and amounts.credit.currency in the transaction model.
Practical expectations
When you prepare a message for Meridian:- send a complete
pacs.008message document, not a fragment - preserve the schema namespace that matches your chosen
pacs.008version - preserve the original identifiers used for the payment instruction
- include exactly one
CdtTrfTxInfblock in each submitted message - keep the XML as the source artifact that you encode and submit
- validate the message against your own network and schema rules before encoding
Document payload, align that packaging with Meridian during onboarding. The ingestion endpoint itself expects the encoded payload to contain the message document you want processed.
Example skeleton
This example shows the shape Meridian expects at a document level. It is intentionally abbreviated and not a complete, schema-valid payment message.Before you submit
Before callingPOST /v1/payout-origination/pacs008:
- Build or receive the complete
pacs.008message document. - Validate the XML and business content in your own system.
- Base64-encode that message document.
- Send the encoded payload to Meridian with HMAC authentication headers and a separate
Idempotency-Keyheader.
Transaction model mapping
Use this section to understand how Meridian maps a submittedpacs.008 message into the internal transaction model that GET /v1/transactions and GET /v1/transactions/{id} expose.
The read APIs return Meridian’s internal transaction model, not the original XML. Each submitted message must contain exactly one CdtTrfTxInf block.
Mapping table
Internal fields
These transaction fields are internal Meridian fields and are not sourced directly from thepacs.008 payload:
statusstatusReasoncreatedAtupdatedAtrelatedTransactionId
Example mapping
Given thispacs.008 fragment: