Dual-Message Integration Guide

👍

Available soon

🚧

Only supported for BCMC

Purpose

This guide describes the merchant/terminal message sequence for a card-present
nexo dual-message transaction routed through IPG to Omnipay.

In dual-message mode, the terminal submits two messages:

1. An authorization message to obtain approval.
2. A completion advice to confirm the terminal outcome and complete the
   transaction.

The terminal, not IPG, initiates the second leg. Do not expect IPG to generate
a completion advice automatically for a dual-message transaction.

This is an integration guide, not a replacement for the applicable nexo ISO
20022 schema or the agreed processor specification.

Supported Message Families

Dual-Message Sale

1. Send the authorization request

For a card-payment Sale authorization, send AcceptorAuthorisationRequest
with the following transaction values:

Example structure:

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:caaa.001.001.06">
  <AccptrAuthstnReq>
    <Hdr>
      <MsgFctn>FAUQ</MsgFctn>
      <PrtcolVrsn>6.0</PrtcolVrsn>
    </Hdr>
    <AuthstnReq>
      <Envt>
        <POI><Id><Id>TERMINAL-123</Id></Id></POI>
      </Envt>
      <Tx>
        <TxCaptr>false</TxCaptr>
        <TxTp>CRDP</TxTp>
        <TxId>
          <TxDtTm>2026-09-18T12:34:56Z</TxDtTm>
          <TxRef>AUTH-REFERENCE-001</TxRef>
        </TxId>
      </Tx>
    </AuthstnReq>
  </AccptrAuthstnReq>
</Document>

IPG returns the authorization response for this leg. Record the response and
retain the three correlation values shown below until the terminal has sent the
completion message.

2. Send the completion advice

After the terminal has completed the transaction, send
AcceptorCompletionAdvice.

Example structure:

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:caaa.003.001.06">
  <AccptrCmpltnAdvc>
    <Hdr>
      <MsgFctn>FCMV</MsgFctn>
      <PrtcolVrsn>6.0</PrtcolVrsn>
    </Hdr>
    <CmpltnAdvc>
      <Envt>
        <POI><Id><Id>TERMINAL-123</Id></Id></POI>
      </Envt>
      <Tx>
        <TxCaptr>true</TxCaptr>
        <TxTp>CRDP</TxTp>
        <TxId>
          <TxDtTm>2026-09-18T12:34:56Z</TxDtTm>
          <TxRef>AUTH-REFERENCE-001</TxRef>
        </TxId>
        <TxSucss>true</TxSucss>
        <Rvsl>false</Rvsl>
      </Tx>
    </CmpltnAdvc>
  </AccptrCmpltnAdvc>
</Document>

IPG sends the completion to the configured authorization network only after it
has correlated the completion with the pending first leg. IPG then returns the
completion response to the terminal.

Correlation Rules

IPG identifies a completion message by this composite key:

Fiserv terminal ID + Tx/TxId/TxRef + Tx/TxId/TxDtTm

The key must identify exactly one pending first-leg transaction. To avoid
rejections or an unintended non-dual-message route:

• Preserve TxRef exactly between the first and second legs.
• Preserve TxDtTm exactly between the first and second legs.
• Send both messages from the same terminal identity.
• Do not reuse the same key for concurrent transactions.
• Do not send a second completion for the same first leg.

Tx/OrgnlTx has a different purpose. It identifies the business transaction
being referenced, for example a Sale being refunded. It does not replace the
current TxId values used to correlate a completion with its first leg.

Transaction Flow Matrix

Terminal Outcome Handling

Successful completion

Send a completion advice with:

TxCaptr = true
TxSucss = true
Rvsl = false

The terminal must await IPG's completion response before treating the
transaction as finally completed.

Technical reversal

A technical reversal is distinct from a terminal-declined completion. Use the
reversal indicator and the applicable failure-reason fields according to the
nexo specification and the agreed processor behavior:

TxSucss = false
Rvsl = true
Failure reason present

Recommended Terminal State Machine

Start
  -> create first-leg TxRef and TxDtTm
  -> send authorization (capture=false)
  -> receive authorization response
  -> retain correlation values
  -> terminal outcome
       -> completed: send completion (capture=true, success=true)
       -> not completed: send completion outcome (success=false), if required by the agreed flow
       -> technical failure: send reversal/cancellation according to the agreed flow
  -> receive and record the response to the submitted second message

Integration Checklist

• Send nexo v6 documents that validate against the applicable caaa
  schema.
• Use FAUQ for the authorization request and FCMV for Sale completion.
• Use CRDP for card-payment Sale legs and RFND for refund legs.
• Set TxCaptr=false for the first authorization leg.
• Preserve the first leg's TxRef, TxDtTm, and terminal ID for the
  completion leg.
• Set TxCaptr=true, TxSucss=true, and Rvsl=false for a successful
  Sale completion.
• Treat OrgnlTx as the business-reference block, not as a replacement
  for the first/second-leg correlation key.
• Handle the response to each leg independently.
• Do not retry a completion with a new reference or timestamp.
• Obtain confirmation for processor-specific field and failure handling
  before enabling refund, preauth/postauth, or cancellation dual-message
  scenarios.

Example: Required Correlation Values