Skip to main content

Create a Return for a Received Payment

This guide explains how to create a SEPA Instant Return for an incoming payment in ImPAI — typically in response to an incoming transaction that cannot or should not be kept on the beneficiary account.

It combines:

  • Return Creation – create the interbank Return for a received SCT Inst payment
    👉 Return Creation API
  • Return Approval (if needed) – approve or reject the return under the Four-Eyes Principle
    👉 Return Approval API

Prerequisites​

Before you start:

  • ✅ You have valid OAuth access tokens and the required roles/permissions.
  • ✅ A SEPA Instant payment has been received and booked on a customer account.
  • ✅ There is a valid reason to send the funds back (e.g., wrong account, technical issue, regulatory restriction).
  • ✅ The transaction is in a state where a Return is allowed under scheme and internal rules.

Step 1️⃣ – Identify the Incoming Payment​

A Return is always based on an incoming credit that has already been processed.

Common ways to select the transaction:

  • From the Transactions UI, filtering for incoming (In) SEPA Instant payments.
  • From a transaction list API, filtering by account, date, or identifiers.
  • From monitoring / fraud systems detecting an issue with the credit.

Check that:

  • the payment is not already subject to a Return or Recall, and
  • the cut-off and scheme rules for returning the payment are still satisfied.

Step 2️⃣ – Create the Return​

To instruct that the funds should be sent back, use the Return Creation API:

POST /api/sct-inst/v1/return/create

This creates a pacs.004 Return message linked to the original incoming credit transfer.

What the call requires (conceptually)​

The Return request is usually structured around:

  • Identifiers
    A reference to the original incoming SCT Inst transaction (for example the credit ID) to ensure precise linkage.
  • Return Details
    This includes:
    • a return reason code describing why the funds are sent back
    • optional additional information for investigation or customer communication

ImPAI verifies that the referenced payment:

  • exists,
  • is a valid incoming SCT Inst transaction,
  • can be returned according to its current state and scheme rules.

Typical return workflow​

  1. Select the incoming SCT Inst payment that must be returned.
  2. Build the Return request with the correct reason and references.
  3. Send POST /return/create with the required headers, such as Authorization and X-Request-Id.
  4. ImPAI validates eligibility, status, and business rules.
  5. If accepted, ImPAI creates a Return transaction and generates the interbank pacs.004 message.

What you get back​

If the return is accepted:

  • You receive technical identifiers (such as a responseId and the original request reference).
  • The payload includes a return transaction identifier, which you can store in your system.
  • The original incoming transaction is marked as returned (or “return in progress”) depending on configuration.

::info Full Details For full schema definitions and response examples, see: 👉 Return Creation API
:::

Step 3️⃣ – Check for Approval Required​

Your internal policies may require manual approval before sending a Return — for example for high-value payments or certain reason codes.

You can detect this similarly to other flows:

  • Check the status returned by the creation call.
  • View the transaction in an Approvals UI (if available).

If the Return is Approval Pending, continue with Step 4.
If not, the Return is processed automatically and you only need to monitor the outcome.

Step 4️⃣ – Approve a Return (Optional)​

If the Four-Eyes Principle applies, an authorized user must approve or reject the Return.

Use:

POST /api/sct-inst/v1/return/approval

What the call requires (conceptually)​

The approval request includes:

  • Identifier
    The internalId of the Return transaction that is pending approval.
  • Decision
    Whether to approve (send Return) or reject (cancel the Return process).
  • Rejection Reason (if applicable)
    A free-text reason, stored for audit and operational review.

ImPAI validates:

  • permissions and roles,
  • that the Return is still Approval Pending, and
  • that the decision is consistent with the transaction state.

What you get back​

On successful approval or rejection:

  • The Return is released for execution (pacs.004 sent) or stopped.
  • The response confirms the decision and may provide updated identifiers or status information.
  • The decision and reason (if provided) are logged for compliance.
Full Details

See the full approval schema and examples here: 👉 Return Approval API

Step 5️⃣ – Track the Return Outcome​

After a Return is sent or rejected:

  • Use your UI (or internal monitoring) to check the final status.
  • The original incoming payment will typically be marked as returned, with links to the Return transaction.
  • Interbank responses (e.g. pacs.002 status messages) can be used to confirm that the Return was processed successfully by the counterparties.

Example Flow at a Glance​

Summary​

  • Use Return Creation to send funds back for a received SCT Inst payment.
  • Optionally, apply the Four-Eyes Principle for manual approval of the Return.
  • Use Return Approval to approve or reject the return request.
  • Monitor final status in your UI and, where applicable, via interbank status messages.

APIs Used in this Flow

StepAPIPurposeDetails
CreationPOST /return/createCreate Return👉 Go
Approval (optional)POST /return/approveRelease Return👉 Go