Payment accepted

Payment accepted — one event shape across every method.

topropay normalises the 'payment accepted' event across cards, wallets, bank rails, BNPL and crypto. The merchant integrates one webhook handler; every accepted authorisation writes a vault-token-keyed row to the unified ledger, regardless of which underlying rail cleared it.

Book an event-model walk-through Read the API docs
webhook.payment_accepted
  1. idpay_4f8a9c20
  2. statusaccepted
  3. amount18900
  4. currencyEUR
  5. methodcard
  6. acquirer_idacq_eu_03
  7. route_score0.84
  8. vault_tokenvt_9421
  9. ms184
  10. ts2024-09-04T14:21:08Z
Same shape across card, iDEAL, PIX, SEPA, BNPL, crypto.
Event
signed, normalised, replay-safe
300+
accepted payment methods
<200ms
routing to acceptance
1 ledger
for every accepted receipt

Lifecycle

From accepted for processing to settled in five states

Every authorisation moves through the same five states regardless of method. Each state writes a normalised event the merchant's stack can consume off one webhook handler.

  1. 01
    accepted_for_processing

    Accepted for processing

    The authorisation has been validated, scored by the routing engine and dispatched to the chosen acquirer. The merchant sees the event in the operator portal in real time; the customer sees a 'processing' UI on their side.

  2. 02
    authorised

    Authorised — payment accepted

    The acquirer has confirmed the authorisation. A 'payment accepted' webhook fires with the normalised event payload. The merchant's order-management system marks the order paid; the platform writes a vault-token-keyed row to the ledger.

  3. 03
    captured

    Captured

    Funds are pulled from the issuer (immediate capture for most methods; delayed capture for travel, ticketing or staged-capture patterns). The capture event normalises into the same webhook stream.

  4. 04
    settled

    Settled

    Funds land in the merchant's settlement account on the connected acquirer's settlement cycle. The settlement row in the unified ledger references the original authorisation by vault-token ID.

  5. 05
    refunded

    Refunded (if applicable)

    Merchant-initiated refunds run through the same API surface. The refund event normalises into the same webhook stream; the ledger row is updated with the refund reference and net amount.

Key benefits

Why a normalised payment accepted event matters

Four outcomes that show up consistently once the merchant's stack consumes one normalised acceptance event rather than per-provider, per-method event shapes.

  1. 01

    One 'payment accepted' event across every method

    Whether the underlying rail is a card, an iDEAL bank-redirect, a PIX QR confirmation, a SEPA mandate or a partner-crypto on-chain credit, the merchant receives the same shape of signed webhook event. The operator-portal row and the reconciliation feed treat them identically — methods differ; the acceptance shape doesn't.

  2. 02

    Visibility into the accepted-for-processing window

    The operator portal surfaces the accepted-for-processing state as a first-class lifecycle stage. Merchants see which authorisations are mid-route, which acquirer is processing them, and how long the in-flight window has been open. No more guessing what the gateway is doing between submit and confirm.

  3. 03

    Hundreds of accepted payment methods on one API

    Cards, wallets, bank rails, BNPL and (via partner gateways) crypto all behave like one method category from the merchant's integration perspective. Method availability per market is dashboard-configurable; the accept call shape is identical across them.

  4. 04

    One ledger keyed off the accepted authorisation

    Every accepted authorisation writes a row that the subsequent capture, refund and chargeback events update in place. Finance closes the month from one export; disputes share a single timeline keyed off the vault-token identifier of the original accepted payment.

Main use cases

Where the accepted event drives merchant-side work

Six merchant shapes that all consume the same payment accepted event but trigger different downstream flows from it.

  • DTC

    Online retail order confirmation

    The 'payment accepted' webhook is the trigger to ship — order-management systems and warehouse pickers read off the same event. Because every method writes the same shape, the OMS doesn't need per-method branches.

  • SaaS

    Subscriptions and trial conversions

    On sign-up, payment accepted is the moment the subscription becomes active and the welcome email fires. Renewals reuse the vault token; each renewal cycle writes a new 'payment accepted' event under the same subscription record.

  • Plat

    Marketplaces and platforms

    Per-seller acceptance events fire with split-payment metadata. The marketplace's seller-ledger updates row-by-row; the platform's reconciliation feed rolls them up by tenant.

  • Travel

    Travel and ticketing — staged captures

    Payment accepted at booking (deposit, with the rest staged); subsequent captures reference the original accepted authorisation. The booking timeline shows all events keyed off the original.

  • B2B

    B2B invoice payments

    Invoice paid via card, ACH, SEPA or PIX — all fire the same payment accepted event with invoice metadata preserved. The merchant's invoicing system updates the invoice status from one webhook handler.

  • Donor

    Donor and nonprofit flows

    Recurring and one-off donor payments accepted through the same engine. Gift-aid metadata, donor-portal records and tax-receipt fields are preserved on the acceptance event for downstream consumption.

Platform features

Capabilities behind the payment accepted lifecycle

What the platform ships for the acceptance side specifically — the event model, the in-flight visibility, the audit trail and the reconciliation primitives.

  • Signed acceptance event

    Every accepted authorisation fires a signed (HMAC), replay-safe webhook with normalised fields — same shape across every accepted payment method.

  • Accepted-for-processing visibility

    Operator portal surfaces the mid-route state in real time; acquirer ID and routing policy are visible per in-flight authorisation.

  • Vault-token continuity

    The acceptance event carries a vault-token identifier; every subsequent capture, refund and chargeback event references the same token.

  • Normalised event payload

    Predictable JSON shape with amount, currency, method, acquirer ID, route score and timing — across cards, wallets, bank rails, BNPL and crypto.

  • Idempotency keys

    Idempotency keys on the authorise endpoint prevent duplicate accepted events on network retries from the merchant side.

  • Replay-safe webhook delivery

    Webhook retries follow exponential back-off until acknowledged or until a configurable deadline; deduplication keys included for safe replay.

  • Sandbox parity

    Sandbox triggers deterministic 'payment accepted' events including specific decline-reason scenarios, 3DS challenges, iDEAL bank-confirmation, PIX bank-credit timing, ACH R-code rejections.

  • Operator portal queue

    Authorise / accepted / settled / refunded / disputed queues in one dashboard — across web, mobile and embedded surfaces.

  • Per-method analytics

    Acceptance rate, in-flight time, cascade hit-rate and route-score distribution surfaced per method, per acquirer, per region.

  • Unified reconciliation

    Daily exports include the accepted-authorisation row, the capture, the settlement reference and any subsequent refund / chargeback — keyed off the vault token.

Trust & compliance

Compliance posture around the accepted event

Every accepted authorisation runs through a single audited environment. Webhook signing, vault tokens and audit logging make the acceptance event safe to consume from any merchant stack.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture for every accepted authorisation.
Signed events
Replay-safe webhook delivery with HMAC signatures; SIEM-friendly out of the box.
Tokenised identifiers
Vault-token identifiers in event payloads; PAN never leaves the platform. Refund and dispute responses operate on tokens, not card numbers.
Audit log
Every accepted authorisation, refund and operator action logged with actor identity, reason code and timestamp — surfaceable for compliance and audit.
Data residency
Regional data-residency options for merchants under regulators that require it; EU-resident traffic stays in-region by default.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of integration shape.

Ready to integrate

One payment accepted event. Every method, one webhook handler.

A 30-minute event-model walk-through covers the normalised payload, the accepted-for-processing window, idempotency semantics, and a sandbox that triggers deterministic acceptance outcomes for your testing.

Book an event-model walk-through Read the API docs

Frequently asked

Buyer questions about the payment accepted event

Questions buyers ask before wiring the acceptance event into their stack — lifecycle semantics, idempotency, retention, sandbox parity and downstream OMS integration.

  1. 01

    What does 'payment accepted' mean inside topropay's data model?

    Payment accepted on topropay is the event that fires when an acquirer has confirmed an authorisation — funds reservation against the issuer is done, the merchant can ship the order. The event is signed, normalised and replay-safe; every accepted authorisation writes a vault-token-keyed row to the unified ledger.

  2. 02

    What's the difference between accepted_for_processing and authorised?

    Accepted_for_processing means the authorisation has been validated, scored by the routing engine and dispatched to the chosen acquirer — but the acquirer hasn't yet confirmed. Authorised (the 'payment accepted' event) means the acquirer has confirmed. The mid-route state is surfaced in the operator portal so merchants can see which authorisations are in flight.

  3. 03

    How long does the accepted-for-processing window typically last?

    For cards, accepted_for_processing typically lasts hundreds of milliseconds to a couple of seconds — the time between dispatch and the acquirer's authorisation response. For methods like iDEAL or PIX the window can extend to minutes while the buyer interacts with their bank app; the platform exposes a per-method timeout policy.

  4. 04

    What accepted payment methods are available out of the box?

    Accepted payment methods include cards (Visa, Mastercard, Amex, Discover, JCB, RuPay), wallets (Apple Pay, Google Pay, Click to Pay), bank rails (SEPA, Bacs, Open Banking, iDEAL, BLIK, PIX, OXXO, PayID), BNPL (Klarna, Afterpay, Affirm, Clearpay) and crypto via licensed partner gateways. Per-market availability is dashboard-configurable.

  5. 05

    Is the 'payment accepted' event identical across all accepted payment methods?

    The event shape is identical — same field names, same normalised structure, same signing. The method-specific metadata (BIN for cards, bank end-to-end ID for PIX, iDEAL bank reference, etc.) sits in a method-specific sub-object so merchants who don't need it can ignore it.

  6. 06

    How are duplicate accepted events avoided on network retries?

    Idempotency keys on the authorise endpoint prevent duplicate acceptances. If the merchant retries the same idempotent call after a network blip, the platform returns the original accepted event rather than creating a new authorisation. Webhook delivery itself is replay-safe with deduplication keys.

  7. 07

    What happens when an authorisation moves from accepted_for_processing into a soft decline?

    If the chosen acquirer returns a soft decline, the routing engine cascades to the next ranked acquirer inside the same request. The accepted-for-processing state continues until either an acquirer confirms (then 'payment accepted' fires) or the cascade is exhausted (then a decline event fires). The merchant sees one final result, not a sequence of per-provider attempts.

  8. 08

    Can I subscribe to only the accepted events and not the intermediate ones?

    Yes. Webhook subscriptions are per-event-type. Merchants can subscribe only to 'payment accepted' (and 'refunded' / 'disputed') if the intermediate accepted_for_processing state isn't useful to their stack. The operator portal still surfaces every state regardless of subscription.

  9. 09

    How does the accepted event tie to the settlement row in reconciliation?

    Every accepted authorisation writes a row to the unified ledger keyed off the vault-token identifier. When the connected acquirer settles, the settlement row carries the same vault-token reference and points back to the original accepted authorisation. The reconciliation export joins the two without manual matching.

  10. 10

    Are accepted events kept for the long term?

    Accepted events are retained according to the platform's data-retention policy (scheme-aligned for card, regulatory-aligned for bank rails, longer for high-volume merchants who configure extended retention). The signed event log is surfaceable from the dashboard for audit.

  11. 11

    Can the accepted event drive my order-management system?

    Yes — that's the canonical use. The 'payment accepted' event is the trigger to mark the order paid, release the warehouse pick, fire the confirmation email and update the customer-portal record. Because the event shape is identical across methods, the OMS handler doesn't need per-method branches.

  12. 12

    What if my accepted authorisation needs to be voided before capture?

    Authorise / void is supported through the same API — POST to /v1/payments/:id/cancel before capture. The cancel event normalises into the same webhook stream; the ledger row is updated with the cancellation reference. After capture, the equivalent flow is a refund.

  13. 13

    How does accepted behave for staged-capture flows like travel?

    Staged captures fire 'payment accepted' on the initial authorisation (the deposit or hold), then subsequent capture events as the merchant pulls the funds in stages. Each capture references the original accepted authorisation; the ledger updates in place. The customer-side timeline shows one acceptance plus N captures.

  14. 14

    Is there a separate accepted event for refunds, or is it the same shape?

    Refunds fire their own event ('payment refunded') with the same normalised shape as accepted — including the original vault-token reference. From the merchant's webhook handler, it's a switch on the event type; the field model is consistent.

  15. 15

    How does the sandbox simulate accepted-for-processing → accepted timing?

    Sandbox endpoints accept deterministic helpers — pass an in-flight time in the test header and the sandbox will hold the authorisation in accepted_for_processing for that duration before transitioning to accepted (or to the configured decline reason). Useful for testing UI behaviour during the in-flight window.

Related

Related on the topropay platform