Third-Party SEPA Payins

With Payment Accounts enabled and the user's consent recorded, incoming SEPA transfers whose sender is not the account holder are accepted and held under a lien until the sender's sanctions screening concludes — nothing is credited before the verdict. For a clear sender that is typically a matter of seconds; a sender the platform has already cleared before credits effectively immediately.

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.

The lien, step by step

1. The payment arrives and is matched to the account. If the sender's name is the account holder's, it is a first-party payin — credited as always, nothing below applies.
2. While screening runs, the funds are held under a lien. The account object carries a lienAmount ({ amount, currency }) for the total held, and the first page of /wallets/get/account/statement shows a provisional row for the payment: status: "LIEN", lien: true, txType: "SEPA_PAYIN_COMPLETED", with the full sender fields (bankingSenderName, bankingSenderIban, bankingSenderBic, reference). The held amount is not part of the available balance.
3. Clear verdict → automatic credit. The lien releases, the credit lands on the account, the SEPA_PAYIN_COMPLETED TRANSACTION webhook is delivered at credit time, and the payin fee (if configured) is collected. The provisional LIEN row is replaced by the ordinary credited row (a different row id — treat LIEN rows as provisional, don't key long-lived state on their ids).
4. Screening keeps one record per counterparty name, shared across your users: once a sender has been cleared, further payments from that person — even from a different bank account — credit without a visible hold.

When a hold needs a human

If the verdict needs manual compliance review, the payment simply stays held. After a hold has stood for roughly five minutes, a neutral TRANSACTION_UNDER_REVIEW event is delivered once on the TRANSACTION webhook channel so you can tell your user the payment is under review: { type, transactionId, accountId, userId|businessId, txType, amount, currency, heldAt }. No reason is included. The hold then ends in one of two ways:

Behavioral notes for your integration

• SEPA_PAYIN_COMPLETED arrives at credit, not at receipt. For most third-party payins that is seconds after arrival; for a held payment it is whenever the review clears.
• Standing orders trigger on credit. A standing order on the account executes after the funds actually credit, under its own transaction span; the payin credit row does not carry standingOrderId / standingOrderSpanId — don't infer "no standing order ran" from the credit row.
• Rare post-credit reverts still exist. Independently of the lien flow, compliance can in rare cases revert an already-credited payin: the statement shows a SEPA_PAYIN_REVERTED debit carrying the original bankingTransactionId; if the case is dismissed the funds return as a new SEPA_PAYIN_COMPLETED credit (same bankingTransactionId, new row id). Key your row ingestion on the row id, not on bankingTransactionId alone, or the returning credit may be dropped by your deduplication.
• Rare MANUAL_ADJUSTMENT rows can still appear on statements for adjustments made by Lightspark Payments Europe outside any payment context; render them neutrally.

These rows appear in /wallets/get/account/statement, /wallets/account/get-transactions-by-id, and their business and corporate equivalents.

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 and payouts — including every screening and Verification of Payee outcome — on the sandbox environment. See Testing in Sandbox.