How incoming SEPA payments from third parties behave on Payment Accounts
With Payment Accounts enabled and the user's consent recorded, incoming SEPA transfers whose sender is not the account holder are accepted and credited immediately for SEPA Instant payments per scheme rules.
Without the feature (or without consent), third-party payins keep the previous behavior: they are held for compliance review and only credited if approved. Recording consent affects future payins; it does not retroactively release earlier holds - those follow the normal review process.
What changes for your integration
No new webhook types. No schema changes. Every field in the SEPA_PAYIN_COMPLETED payload (see Bank Transfer Webhooks) and in transaction rows is unchanged. If your consumer switches exhaustively on txType, nothing new will appear in the stream. Four behavioral notes:
1. SEPA_PAYIN_COMPLETED arrives at receipt
SEPA_PAYIN_COMPLETED arrives at receiptFor Payment Account payins the SEPA_PAYIN_COMPLETED TRANSACTION webhook is delivered when the payment arrives and the funds are immediately credited.
2. The payin fee is collected after mandatory screening clears
The APPLICATION_FEE webhook and the fee debit on the statement now follow the screening verdict rather than the credit itself — typically seconds later, occasionally up to ~10 minutes. The fee amount and payload shape are unchanged.
3. Standing orders trigger after screening clears
A payin credit row for a Payment Account does not carry standingOrderId / standingOrderSpanId even when the account has an active standing order. The standing order executes after the screening verdict, under its own transaction span. Don't infer "no standing order ran" from the credit row.
4. A payin can be reverted and can come back
If there is a compliance reason found on an already-credited payin, the credited amount is taken back: the statement shows a SEPA_PAYIN_REVERTED debit carrying the same bankingTransactionId and sender fields as the original payin. If the case is later dismissed, the funds return as a SEPA_PAYIN_COMPLETED credit - again with the original payin's bankingTransactionId but a new row id.
Key your row ingestion on the row id, not on bankingTransactionId alone otherwise the returning credit may be dropped by your deduplication.
These rows appear in /wallets/get/account/statement, /wallets/account/get-transactions-by-id, and their business and corporate equivalents. No webhook is sent for either row.
Outcomes of a payin
| Monitoring outcome | What happens | What you see |
|---|---|---|
| Clear | Fee collected, standing order (if any) runs | APPLICATION_FEE webhook; normal statement rows |
| Match | The credited amount is taken back pending review | A SEPA_PAYIN_REVERTED debit on the statement; no webhook |
| Match dismissed | Funds returned to the account | A SEPA_PAYIN_COMPLETED credit (same bankingTransactionId, new row id); no webhook |
| Match confirmed | The payment is returned to the sender's IBAN | Nothing further — the earlier SEPA_PAYIN_REVERTED debit already completed the account's arithmetic; no additional webhook is sent for the refund |
Rare MANUAL_ADJUSTMENT rows can still appear on statements for adjustments made by Lightspark Payments Europe outside any payment context; render them neutrally.
First-party payins
Payins where the sender name matches the account holder are unaffected — same behavior, same timing, same webhooks as today.
Trying it out
You can simulate third-party payins — including the sanctions-match flow — on the sandbox environment. See Testing in Sandbox.