SEPA Direct debit and girocard

📘

Your account must be enabled for this feature

🚧

Girocard is limited to Germany. Direct Debit is limited to SEPA.

Use this guide to accept girocard and SEPA Direct Debit (SDD), also known in Germany as electronic direct debit or ELV, through the Fiserv Gateway using the nexo Acquirer protocol.

Availability depends on your merchant agreement, store and terminal configuration, terminal certification, and the capabilities enabled by Fiserv. Contact your Fiserv representative before starting an integration or enabling a new transaction path.

Overview

A girocard can support more than one payment route. The terminal must select the intended route and send the corresponding value in Envt/Card/CardBrnd.

The value in CardBrnd is case-sensitive. Do not infer approval from the selected route: always evaluate the authorization response.

Before you begin

Confirm that:

• your Fiserv merchant account, store, and terminal are enabled for the required girocard and/or ELV services;
• your terminal model and software are certified for the transaction paths you intend to use;
• you have the assigned Store ID, Merchant ID, and Terminal ID;
• the terminal can read contact EMV and, for girocard, any certified contactless interface;
• the terminal supports the required PIN and/or signature flows;
• the terminal can display host-provided messages and print all required receipt data;
• production Terminal IDs for Germany have been assigned through the applicable German business process.

Follow the general nexo security requirements for transport authentication, message integrity, PIN handling, and protection of card data. Never place live PAN, track data, PIN data, cryptographic keys, or unmasked customer information in source control or support tickets.

Required identifiers and transaction counter

Include the identifiers assigned during onboarding in every request:

For transactions routed to the German authorization platform, manage TxRef as follows:

• Use a numeric value in the range 000000 to 999999.
• Make it unique for each request/response message pair. A technical cancel may reuse the original transaction ID where permitted by the nexo specification.
• Increase the counter between new transactions. An increment of 10 is recommended so the Gateway can use intermediate values during automatic cutover or routing.
• After values above 900000, the counter may restart below 100000.
• If a response reports a different downstream STAN in TxRspn/AuthstnRslt/TMSTrggr, continue to reference the transaction with the original TxRef, not the downstream STAN.

See References and Identifiers for the complete identifier rules.

Select the payment route

The following fragments show only the fields that distinguish these flows. Add them to a complete, schema-valid nexo request containing your assigned identifiers, card data, amount, currency, EMV data, capabilities, and message authentication data.

girocard

Set CardBrnd to G:

<Envt>
  <Card>
    <!-- Protected or permitted card data omitted -->
    <CardBrnd>G</CardBrnd>
  </Card>
</Envt>

The terminal selects the card-entry method and cardholder verification method from the card, terminal configuration, and EMV outcome. A contactless girocard transaction can be processed online with either:

• no cardholder verification method, when permitted; or
• online PIN.

Whether a transaction is processed online or offline also depends on the applicable terminal limits and EMV decisioning.

Co-branded payment

When the terminal and card select a supported co-brand, send the corresponding brand value:

<!-- Maestro -->
<CardBrnd>E</CardBrnd>

<!-- V PAY -->
<CardBrnd>P</CardBrnd>

Do not send G when the terminal has selected the co-brand route. The resulting transaction is governed by the selected co-brand scheme rather than the girocard route.

SEPA Direct Debit / ELV

For ELV, set CardBrnd to L and use contact EMV card entry:

<Envt>
  <Card>
    <!-- Protected or permitted card data omitted -->
    <CardBrnd>L</CardBrnd>
  </Card>
  <Crdhldr>
    <TxVrfctnRslt>
      <Mtd>PPSG</Mtd>
      <Rslt>SUCC</Rslt>
    </TxVrfctnRslt>
  </Crdhldr>
</Envt>
<Cntxt>
  <PmtCntxt>
    <CardPres>true</CardPres>
    <CrdhldrPres>true</CrdhldrPres>
    <CardDataNtryMd>CICC</CardDataNtryMd>
  </PmtCntxt>
</Cntxt>

In each TxVrfctnRslt entry, use the signature method and result produced by your terminal. The signature method belongs in TxVrfctnRslt/Mtd; TxVrfctnRslt/Rslt reports whether that verification succeeded.

ELV is supported for contact-chip entry (CICC). If the girocard instrument is read using the contactless interface, it is processed as girocard rather than ELV.

girocard emergency processing

Emergency processing is a fallback path and must only be used when permitted by the card, terminal certification, scheme rules, and your Fiserv configuration.

Indicate the applicable fallback result in Cntxt/PmtCntxt/FllbckInd:

<Cntxt>
  <PmtCntxt>
    <CardDataNtryMd>CICC</CardDataNtryMd>
    <FllbckInd>FFLB</FllbckInd>
  </PmtCntxt>
</Cntxt>

Supported emergency values are:

• FFLB — fallback after a failed card-reading attempt;
• SFLB — fallback after a successful card-reading attempt.

Include the required ICCRltdData defined by the applicable Deutsche Kreditwirtschaft Technical Annex and DC POS specification. Do not manufacture EMV data or choose a fallback value without a corresponding terminal outcome.

ELV processing options

Offline ELV

For offline ELV, the terminal makes the local decision and verifies the signature before sending an AcceptorCompletionAdvice to the Gateway.

Requirements include:

• Envt/Card/CardBrnd = L;
• Cntxt/PmtCntxt/CardDataNtryMd = CICC; and
• TxVrfctnRslt/Mtd = PPSG or CPSG, with the applicable verification result in TxVrfctnRslt/Rslt.

Online ELV

For online ELV, send an AcceptorAuthorisationRequest before the transaction is finalized. Fiserv returns an authorization decision based on the configured checks. Report the terminal's signature method as PPSG or CPSG in TxVrfctnRslt/Mtd and the applicable verification outcome in TxVrfctnRslt/Rslt.

The Gateway may accept other schema-valid verification values, but the authorization platform or issuer can decline the transaction. Your terminal should restrict ELV to the certified signature flow.

Optional risk services

These services are configured by Fiserv; they are not selected by adding a different field to the terminal request.

Display instructions

For certified girocard processing, the authorization platform can return text that must be displayed on the terminal. A display instruction has this structure:

<Actns>
  <ActnTp>DISP</ActnTp>
  <MsgToPres>
    <MsgDstn>MDSP</MsgDstn>
    <MsgCntt>Message supplied by the authorization platform</MsgCntt>
  </MsgToPres>
</Actns>

When ActnTp is DISP, present MsgToPres/MsgCntt at the destination identified by MsgToPres/MsgDstn. Do not replace host-provided scheme text with a generic approval or decline message.

TSD+ fall-forward to girocard

An online ELV transaction can be declined with response code 62. If the response also contains an action with ActnTp = FLFW, the terminal should offer or initiate a new, separate girocard contact transaction according to its certified user flow.

<Actns>
  <ActnTp>FLFW</ActnTp>
</Actns>

Important:

• FLFW is an instruction to start a new girocard attempt; it is not approval of the ELV attempt.
• Use CardBrnd = G for the new girocard request.
• Use a new TxDtTm and a new TxRef for the new transaction attempt.
• Do not retry indefinitely. If the girocard attempt is declined or cannot be completed, end the payment flow and inform the cardholder.
• FLFW is supported by the nexo 6 authorization response model. It is not available as an action type in the nexo 5 response model checked for this guide. Agree the required message version and behavior with Fiserv during certification.

Receipt requirements

ELV receipts must include the International Bank Account Number (IBAN) required for the direct debit mandate and receipt flow. When it is available in the authorization response, the Gateway places the IBAN in EMV tag 5F53 within ICCRltdData.

Your terminal must:

• parse tag 5F53 from the response ICCRltdData;
• print the required IBAN representation on the receipt;
• avoid displaying or logging more account data than required; and
• comply with the receipt format agreed during certification.

Refunds

The girocard scheme does not provide a native card refund transaction. After a girocard purchase has completed, return funds using the SEPA credit-transfer flow agreed with Fiserv.

This refund is a new credit transaction to the customer's bank account. It does not reverse the original girocard authorization or change the original purchase status. If the original transaction has not completed, use the certified cancellation or reversal process instead of creating a refund.

Refund prerequisites

Before sending refunds, confirm that:

• SEPA credit-transfer refunds are enabled for the merchant, store, and terminal;
• the terminal is certified to obtain the beneficiary account data through the agreed card-reading or account-data flow;
• Fiserv has confirmed whether your integration uses online refund requests, refund advices, or both;
• referenced and unreferenced refunds are enabled as required;
• full and partial refunds are supported by your agreement; and
• your operational process covers duplicate prevention, reconciliation, and customer enquiries.

Do not construct a refund from the masked IBAN printed on a receipt or returned for display. A masked value is not a payment instruction. Obtain account data only through the certified flow and protect it according to the applicable security requirements.

Supported request patterns

Fiserv supports the following nexo request patterns for that flow:

These values identify the request pattern but are not a complete refund message. Include all fields required by your negotiated nexo schema and Fiserv configuration.

Online refund request

The following fragment illustrates the main refund fields. Replace every placeholder and add the complete environment, card/account, context, security, and routing data required by your certified message profile.

<Hdr>
  <MsgFctn>FAUQ</MsgFctn>
  <!-- Protocol version, exchange ID, timestamps and parties omitted -->
</Hdr>
<AuthstnReq>
  <Envt>
    <!-- Merchant, POI and protected card/account data omitted -->
    <Card>
      <CardBrnd>L</CardBrnd>
    </Card>
  </Envt>
  <Cntxt>
    <PmtCntxt>
      <CardPres>true</CardPres>
      <CrdhldrPres>true</CrdhldrPres>
      <CardDataNtryMd>CICC</CardDataNtryMd>
    </PmtCntxt>
  </Cntxt>
  <Tx>
    <TxCaptr>true</TxCaptr>
    <TxTp>RFND</TxTp>
    <!-- Merchant category code omitted -->
    <TxId>
      <TxDtTm>2026-09-01T10:15:30+02:00</TxDtTm>
      <TxRef>120040</TxRef>
    </TxId>
    <InitrTxId>refund-unique-reference</InitrTxId>
    <TxDtls>
      <Ccy>EUR</Ccy>
      <TtlAmt>10.00</TtlAmt>
      <AmtQlfr>ACTL</AmtQlfr>
    </TxDtls>
  </Tx>
</AuthstnReq>

For the German debit/SEPA refund route, CardBrnd=L is normally used. Use the brand and account-data method confirmed for your integration during certification. Do not send CardBrnd=G to simulate a girocard refund.

Send the refund amount as a positive amount in Tx/TxDtls/TtlAmt; TxTp=RFND identifies the credit direction. Do not use a negative purchase amount.

Card can be read in contact (use CardDataNtryMd=CICC) or contactless mode (Use CardDataNtryMd=CTLS).

Referenced and unreferenced refunds

An unreferenced credit creates a refund without linking it to an original Gateway transaction. Use it only when enabled and when your merchant process has independently validated the customer's entitlement and beneficiary account.

A referenced return links the refund to a previous transaction. When required by your message profile, populate Tx/OrgnlTx with the original identifiers captured from the original request and response, such as:

• the original TxId/TxDtTm and TxId/TxRef;
• the original InitrTxId;
• the Gateway-assigned RcptTxId; and
• the original transaction type.

Use the exact reference combination agreed during certification. Do not substitute a downstream STAN for the original nexo TxRef, and do not use identifiers from a different merchant, store, or transaction.

Every refund remains a new transaction and therefore requires its own unique Tx/TxId, Tx/InitrTxId, and reconciliation data, even when Tx/OrgnlTx references the original purchase.

Amount and duplicate controls

• Use EUR for the SEPA credit transfer unless Fiserv has explicitly enabled another supported arrangement.
• Apply your agreed full- and partial-refund rules. Your system should prevent the cumulative refunded amount from exceeding the refundable purchase amount.
• Generate a new TxRef using the normal counter rules and a unique merchant refund reference.
• Persist the refund request before transmission so an uncertain communication result cannot create an uncontrolled duplicate.
• After a timeout, determine the status of the original refund through the agreed recovery or reconciliation process before resubmitting it.
• If a retry is required, follow Fiserv's duplicate-handling guidance; do not silently create a second business refund with unrelated identifiers.

Refund response and customer communication

For an online refund, process the authorization response in the same disciplined way as other online transactions:

1. Correlate the response with the refund request.
2. Evaluate TxRspn/AuthstnRslt/RspnToAuthstn/Rspn and the associated response details.
3. Process all display and print actions in TxRspn/Actns.
4. Store the Gateway transaction identifiers and the original-purchase reference, when present.
5. Include the refund in reconciliation and settlement controls.

An approved response means the Gateway accepted the refund for the configured processing flow. It does not guarantee that the beneficiary bank has already credited the customer's account. Do not promise a fixed posting time unless it is part of your merchant agreement. Give the customer a receipt or reference that your support team can use to locate the refund without exposing full account data.

Refund advice

For a certified advice flow, send an AcceptorCompletionAdvice with MsgFctn=FRVA, TxCaptr=true, and TxTp=RFND. Include the actual outcome and all fields required by the negotiated schema. An advice reports the terminal's completed refund outcome; it must not be used as a generic replacement for an online request.

If the terminal could not complete a refund or the result is uncertain, follow the certified failure, reversal, and reconciliation procedure. Do not send a successful refund advice merely because the terminal displayed a receipt.

Refund limitations

• A SEPA credit-transfer refund is not a girocard card-scheme refund.
• It does not cancel or amend the original purchase.

Do not submit a girocard refund as a standard girocard purchase or by negating the original purchase amount.

Technical cancellation of a timed-out SEPA credit refund

When an online SEPA credit refund times out before the terminal receives a response, send an AcceptorCancellationAdvice (caaa.007) to cancel the refund. Use Hdr/MsgFctn=FRVA, set Tx/Rvsl=true, and identify the refund in Tx/OrgnlTx with the refund's TxId/TxRef, TxId/TxDtTm, and TxTp=RFND.

Use CardBrnd=L on the cancellation advice when the refund was submitted on the SEPA credit / ELV route, even if the original purchase was a girocard transaction with CardBrnd=G. The cancellation applies to the refund transaction, so its brand and protected card data must match the refund, not the earlier girocard sale. Generate new XchgId and TxId/TxRef values for the cancellation advice itself.

For an automatic timeout recovery, include the complete technical-void indicators:

<TxSucss>false</TxSucss>
<Rvsl>true</Rvsl>
<FailrRsn>TIMO</FailrRsn>

TxSucss is required by the caaa.007 schema. FailrRsn=TIMO identifies the cancellation as a technical timeout void; do not rely on a card-purchase integration accepting the message without these indicators.

An APPR response means the Gateway processed the void and the referenced refund was cancelled, so the SEPA credit will not be executed. This applies only while the refund remains voidable. A refund already finalised or settled cannot be cancelled by this advice and must follow the agreed operational reconciliation or compensating-credit process.

If the original refund cannot be found, the Gateway rejects the cancellation advice with ORIGINAL_TRANSACTION_NOT_FOUND; it does not approve it as a successful no-op. Treat this as a cancellation that was not processed. It can mean the refund never reached the Gateway, but it can also indicate a mismatched reference. Reconcile the refund using the exact original identifiers before deciding that no credit exists, and do not create or resend a second refund automatically.