Payment Status Tracking: Webhooks vs Polling and the Open Banking Approach

Payment status looks simple until your first payroll run confirms 400 employees paid and three come back the next morning asking where their salary is.

The payment initiated correctly. The webhook confirmation never arrived. The reconciliation log shows a pending state that nobody acted on.

That gap – between initiated and confirmed – is where most payment workflow failures actually live. Not in the payment itself. In the status tracking around it.

“The mistake platforms make most often with payment status is treating it as a yes/no question. It is a sequence of state transitions. Each one matters. Getting them in the right order, at the right time, is an engineering problem most teams underestimate until they are in production under volume.” – Yuri, Finexer

TL;DR

Polling checks payment status on a schedule – confirmation delay equals the polling interval, API quota burns with volume. Webhooks push status changes as they happen – no quota overhead, real-time confirmation. For Open Banking PIS in the UK, Finexer delivers bank-confirmed instant payment notification via webhook with stable per-payment references and retry logic built in. Card payments use their own processor status feeds – that scope does not change.

What Are the Payment Status States That Actually Matter?

Before choosing how to track payment status, agree on which states your platform tracks and what each one means operationally. Getting this wrong is where reconciliation errors begin.

For account-to-account payments in the UK, the standard lifecycle is:

• Initiated – the payment instruction has reached the bank or PISP. Funds have not moved. This is not confirmation.
• Pending – the payment is in process at the bank. More common on BACS and SEPA than on Faster Payments, where settlement is typically immediate.
• Settled – funds have arrived in the recipient’s account. For Faster Payments, this typically happens within seconds of initiation.
• Failed – the payment was not processed. The failure reason matters: insufficient funds, invalid account details, and bank-side rejection each require a different response from the platform.
• Returned – the payment was sent and returned by the recipient’s bank after settling. Distinct from failed – funds moved out and came back.

The platforms that build reconciliation around initiated as the confirmation checkpoint carry silent exceptions. They surface weeks later as balance discrepancies that look like system errors. They are data model errors.

Why Does Polling Break Down at Scale?

Polling is the default for teams building their first payment workflow. Check a status endpoint on a timer until it returns a terminal state. Readable logic. Works in development.

In production at volume, three things break.

Rate limits hit first. A platform processing 500 payments in a weekly payout run, each polled every 10 seconds, generates thousands of API calls per minute. Payment APIs enforce rate limits per API key. Hit the limit and the API returns a 429 error. The platform then backs off – introducing exactly the confirmation delays it was trying to avoid.

Latency is baked in. Polling interval determines confirmation lag directly. A 10-second polling interval means a payment that is settled at second 1 waits until second 10 to be confirmed. For a checkout flow that is a 10-second freeze on the confirmation screen. For a bulk payout run, that lag compounds across every payment in the batch.

Edge case debt accumulates. What happens when the status endpoint is unavailable mid-poll? When a payment stays pending past the expected window? When the polling loop restarts after a server restart and hits the same payments twice? Each edge case requires explicit handling. That handling accumulates. It becomes the most fragile part of the codebase.

How Does Webhook-Based Payment Status Work?

A webhook is an HTTP POST request from the payment provider to a URL on the platform’s server. When a payment changes state, the provider pushes the update. The platform does not ask – it reacts.

The flow for a settled payment:

1. Platform initiates payment via PIS and stores the payment reference
2. Bank processes and confirms settlement
3. Provider sends POST https://platform.com/webhooks/payments with JSON payload: event type, payment reference, timestamp, amount, status
4. Platform endpoint returns HTTP 200 to acknowledge receipt within ~10 seconds
5. Platform updates its records against the stable payment reference

For this to work reliably in production, three things must be in place from day one.

Signature verification. Providers sign webhook payloads using HMAC-SHA256 with a shared secret. The platform verifies this signature on every incoming request before processing. An unsigned or incorrectly signed payload gets rejected – not processed. Without this, spoofed events can trigger false state transitions in the platform’s records.

Idempotency. Webhook delivery is at-least-once by design, not exactly-once. Providers retry failed deliveries. The same event may arrive more than once. The platform should process each unique event ID once only – store processed event IDs and check before acting. This is not optional at volume.

Retry with exponential backoff. When a platform’s webhook endpoint returns an error, well-implemented providers retry at increasing intervals – 1 minute, 5 minutes, 30 minutes, 2 hours. This is now standard across Stripe, GitHub, and Shopify. The platform’s endpoint should handle a burst of delayed retries on recovery without processing duplicates.

For the full architectural flow – consent, initiation, and confirmation – Open Banking payment flow walks through how these layers connect end-to-end for UK platforms.

What Makes Open Banking Payment Status Different From Card Rails?

Card payments and account-to-account payments use different status models. Conflating them creates architecture problems.

On card rails – Stripe, Adyen, Worldpay – payment status comes from the card processor. The processor sits between the platform and the card network. Status events reflect the processor’s view: authorised, captured, declined, disputed, refunded. The card processor owns the status feed.

On Open Banking PIS, the payment instruction goes directly to the payer’s bank via an FCA-authorised PISP. Faster Payments settle in seconds. The bank-confirmed instant payment notification comes from the bank or PISP – not from a processor intermediary sitting between.

This matters for two reasons specific to UK platforms:

Bank-confirmed carries more weight than processor-confirmed. When the bank confirms a Faster Payment has settled, funds have moved. There is no T+1 clearing window, no intermediate float, no processor-level hold between the PISP and the bank’s confirmation.

The payment reference travels intact. The reference set at initiation flows through Faster Payments to the recipient’s bank account. If structured correctly, it arrives in the recipient’s transaction data unchanged. This is what enables automated reconciliation against live bank records – the reference links the outbound payment initiation to the inbound transaction confirmation without manual matching.

For platforms replacing BACS disbursements with Open Banking PIS, the status model changes significantly. BACS confirmation arrives at the end of a three-day clearing window – reconciliation workflows built for batch end-of-day settlement need rebuilding around per-payment instant payment notification to use the speed difference.

How Does Finexer Deliver Instant Payment Notification?

Finexer’s Open Banking PIS and AIS infrastructure addresses a specific problem that most platforms discover under load: payments initiate in seconds, but the platform needs structured status confirmation – per-payment, at the right state granularity, with a reference that survives the full Faster Payments journey.

The operational gap this solves: a payroll SaaS running salary disbursements for 300 employees initiates 300 Faster Payments. Without per-payment webhook confirmation, there is no reliable way to know which payments settled, which failed, and which need resubmitting – without polling or waiting for bank statement imports.

Finexer PIS delivers per-payment webhook events covering all five status states. Each event carries a stable payment reference tied to the originating instruction and a unique event ID for idempotency. Failure events carry reason codes per payment – not aggregated to batch level.

For platforms using Finexer AIS alongside PIS, payment references can be matched against live bank account transaction data. This provides bank-direct confirmation that the payment appeared in the recipient’s account – not just that the initiation was acknowledged at the provider level.

For how the AIS layer connects to the PIS confirmation loop for reconciliation-grade payment status, Finexer AIS real-time bank data explains the architecture for UK platforms.

Where this changes the operational picture:

Checkout confirmation. A B2B platform using Pay by Bank receives a settled webhook within seconds of the buyer completing SCA. The confirmation screen updates. The order management system marks payment received. No polling loop, no delayed confirmation.

Bulk payroll disbursement. Failed salary payments surface immediately with reason codes. Finance teams action them the same morning – not during month-end reconciliation.

International payouts. For platforms using Finexer’s International Payments capability (GBP to EU and global via licensed payout partners), webhook confirmation covers the UK domestic Faster Payments leg. The EUR settlement confirmation follows from the payout partner – both using a consistent reference structure.

Recurring billing retry logic. A failed payment webhook with an insufficient funds reason code calls for a timed retry. An invalid account details reason code calls for a payment details review before retrying. Webhook-driven retry logic using reason codes produces fewer unnecessary retries than a blanket retry schedule.

What Finexer does not replace here: card processor status feeds (Stripe, Adyen, Worldpay own those), BACS confirmation for platforms still requiring BACS, or AML and sanctions screening – those are separate compliance layers.

FCA-authorised AISP and PISP (FRN 925695). PSD2-compliant. Usage-based pricing, commercial terms agreed based on use case. 3 to 5 weeks of hands-on onboarding support.

“The platforms that build payment status tracking well are the ones that treat idempotency and retry handling as architecture requirements from day one – not as fixes applied after the first production incident. Tracker is built around that assumption.” – Yuri, Finexer

What Does a Production-Ready Webhook Endpoint Look Like?

For engineering teams building the receiver, the checklist that addresses most production failure modes:

Endpoint design:

• Accept HTTP POST only – reject other methods with 405
• Return HTTP 200 immediately on receipt – before processing, not after
• Push processing to an async queue or worker; providers expect a response within ~10 seconds
• Log every incoming event ID before any processing begins

Security:

• Verify HMAC-SHA256 signature on every request using the shared secret
• Reject unsigned or incorrectly signed payloads with 401 – never process them
• HTTPS only – never accept webhook payloads over plain HTTP

Idempotency:

• Store processed event IDs (database or cache with appropriate TTL)
• On each incoming event: check ID first, process if new, return 200 and discard if already seen
• Test duplicate delivery explicitly in your sandbox – most teams do not

Failure handling:

• Log failed processing attempts with event ID and full error detail
• Build a replay mechanism for events that delivered successfully but failed processing
• Monitor endpoint uptime as production-critical infrastructure – a downed endpoint during a payment run creates a backlog of undelivered status events that arrive as a burst on recovery

For a technical walkthrough of how to integrate Open Banking APIs end-to-end including the webhook layer, Open Banking API guide has the full technical walkthrough for UK platform teams.

About the Author

Yuri

Yuriy Yakushko is the Founder of Finexer, an FCA-authorised Open Banking platform that enables businesses to access real-time bank data and Pay-by-Bank payments through secure API infrastructure. With more than 20 years of experience in fintech and software engineering, he focuses on building scalable financial technology that helps businesses modernise payments and financial data workflows.