DEV Community: EcomTrade24 Pay

Your Checkout Redirect Is Not Payment Confirmation

EcomTrade24 Pay — Tue, 30 Jun 2026 08:36:24 +0000

One of the most common mistakes in ecommerce payment integrations is also one of the easiest to miss.

The customer pays, gets redirected to a success page, and the shop marks the order as paid.

It feels logical.

But it is not reliable.

A checkout redirect is not payment confirmation.

It only tells you that the customer's browser reached a certain URL.

That is very different from your backend receiving a trusted payment event.

In real ecommerce, this difference matters a lot.

The redirect is only part of the customer experience

A redirect is useful.

It helps the customer know what happened after checkout.

For example:

/payment/success
/payment/cancel
/order/thank-you

Those pages are good for user experience.

But they should not be the only thing that decides whether an order is paid.

Why?

Because browsers are unreliable.

A customer can close the tab.

A phone connection can drop.

A browser extension can block something.

The redirect can be delayed.

The customer can refresh the page.

The success page can be opened more than once.

A user can manually visit a URL if the logic is weak.

That does not mean the payment was confirmed.

It only means the page was visited.

Payment confirmation belongs on the backend

The backend needs a trusted event from the payment system.

That is usually a webhook.

A cleaner flow looks like this:

Customer starts checkout
Backend creates payment session
Customer is redirected to hosted checkout
Payment provider processes payment
Payment provider sends webhook to merchant backend
Backend verifies webhook
Backend updates order status
Customer sees final status

The important part is this:

Webhook received + verified = backend payment confirmation

The success page should not be the source of truth.

The webhook should be.

This applies to every ecommerce stack

This is not only a WooCommerce problem.

The same rule applies to:

Shopify apps
Custom PHP shops
Laravel stores
Next.js storefronts
Node.js backends
Headless ecommerce
Marketplace platforms
Digital product platforms
SaaS checkout systems
Mobile app backends

The frontend can guide the customer.

The backend must confirm the money.

A simple bad pattern

This is the risky version:

if current_url == "/payment/success":
    mark_order_as_paid()

This is weak because the decision depends on a browser route.

A better version:

on_webhook_received(event):
    verify_signature(event)

    if event.status == "paid":
        mark_order_as_paid(event.order_id)

The customer redirect can still show a nice page.

But the order should only become paid after a trusted backend event.

Webhooks can arrive before or after the redirect

A common reason developers get confused is timing.

Sometimes this happens:

Payment completed
Webhook arrives
Order marked paid
Customer redirects to success page

Other times this happens:

Payment completed
Customer redirects to success page
Webhook arrives later
Order marked paid later

Both are normal.

So the success page should handle both cases.

For example:

Payment received. We are confirming your order.

Then the page can poll the backend or show a pending confirmation state.

The mistake is assuming the redirect and webhook will always happen in the same order.

They will not.

Use clear internal statuses

A good payment integration needs more than paid and failed.

Real payment sessions have more states.

For example:

created
pending
processing
paid
failed
expired
cancelled
review
refunded

This gives your system more control.

A checkout can be created but not paid.

A payment can be pending.

A provider can request review.

A session can expire.

A customer can cancel.

A refund can happen later.

If your system only understands success or failure, you will lose important information.

Do not trust the frontend amount

Another serious mistake is trusting payment data from the frontend.

Bad idea:

{
  "amount": 49.99,
  "currency": "EUR",
  "order_id": "123"
}

If this data comes directly from the browser and your backend does not verify it, you have a problem.

The backend should calculate or load the real order amount from the database.

Better flow:

Frontend sends order_id
Backend loads order from database
Backend calculates amount
Backend creates payment session
Provider returns checkout URL
Frontend redirects customer

The browser should not decide the final price.

The backend should.

Verify the webhook

A webhook endpoint should not blindly accept requests.

At minimum, think about:

Signature verification
API key or token validation
Expected event type
Matching payment session ID
Matching amount and currency
Duplicate event handling
Safe logging
Internal status mapping

A webhook endpoint is a public URL.

Treat it like one.

Bad pattern:

on_webhook_received(request):
    mark_order_as_paid(request.order_id)

Better pattern:

on_webhook_received(request):
    verify_signature(request)
    event = parse_event(request)

    payment = find_payment(event.payment_id)

    if payment.already_processed:
        return success_response()

    if event.amount != payment.expected_amount:
        flag_for_review()
        return success_response()

    if event.currency != payment.expected_currency:
        flag_for_review()
        return success_response()

    update_payment_status(event.status)
    update_order_status(payment.order_id)
    mark_event_processed(event.id)

    return success_response()

The exact code depends on your stack, but the principle stays the same.

Verify first.

Update second.

Log everything.

Make webhook processing idempotent

Payment providers may send the same webhook more than once.

That is normal.

Your system must handle duplicates safely.

A duplicate webhook should not create duplicate wallet credits, duplicate invoices, duplicate licenses, duplicate subscription periods or duplicate order fulfillment.

Use something like:

event_id
payment_id
order_id
processed_at
status_before
status_after

Before applying a webhook event, check whether it was already processed.

if event_id_already_processed(event.id):
    return success_response()

This one rule prevents many ugly bugs.

Return success after safe handling

If your webhook endpoint receives a valid event and processes it safely, return a success response.

If you return an error after processing, the provider may retry.

That can be okay if your system is idempotent, but it creates noise.

A clean webhook handler should:

Receive event
Verify event
Process safely
Store event
Return success

If something is suspicious, you can still store it and flag it for review.

Do not lose the event.

Your customer page should be honest

The customer success page should not lie.

If the backend has already confirmed the payment, show:

Payment confirmed. Your order is now being processed.

If the webhook has not arrived yet, show:

Payment received. We are confirming the final status.

If the customer cancelled, show:

Payment was not completed. You can try again or choose another method.

If the session expired, show:

This payment session has expired. Please create a new checkout.

Clear status messages reduce support tickets.

Logs are part of the product

Payment logs are not just developer tools.

They help merchants, support teams and finance teams understand what happened.

A useful payment log should show:

Checkout session created
Customer redirected
Provider selected
Payment method selected
Webhook received
Status changed from pending to paid
Order updated
Customer redirect completed

When something fails, the log should also show the reason if available.

Without logs, support becomes guesswork.

And with payments, guesswork is expensive.

Payment routing makes this more important

If your system supports more than one provider or method, clean status handling becomes even more important.

A payment may be routed to:

Card
Bank transfer
Wallet
Crypto
Local payment method
Manual payment link
Fallback provider

Each route may have its own provider status names.

Your internal system should normalize them.

Example:

Provider A: completed  -> internal: paid
Provider B: success    -> internal: paid
Provider C: settled    -> internal: paid
Provider D: confirmed  -> internal: paid

This keeps your merchant dashboard and shop integration clean.

The merchant should not need to understand every provider's internal language.

A practical checklist

Before your payment integration goes live, ask:

Can the backend create the payment session?
Is the amount loaded from the database, not trusted from the browser?
Is the customer redirected to a secure hosted checkout?
Does the backend receive webhooks?
Are webhooks verified?
Are webhook events idempotent?
Are amount and currency checked?
Are internal statuses normalized?
Can the order be pending while confirmation is still processing?
Can the system handle expired sessions?
Can the customer retry payment?
Can support see a useful payment log?
Can the merchant understand what happened without reading server logs?

If not, the integration is not finished.

It only works when everything goes perfectly.

Production ecommerce is not perfect.

Final thought

A success page is not a payment confirmation.

It is only part of the customer journey.

The real confirmation should happen on the backend through verified webhook events, safe status handling and clear order updates.

That is true whether you are building for WooCommerce, Shopify, Laravel, Next.js, a custom PHP shop or a headless ecommerce system.

A good checkout should feel simple to the customer.

But behind the scenes, the system needs to be strict.

Confirm the payment on the backend.

Keep the redirect for the customer experience.

Log what happened.

Handle retries safely.

Never build a payment system that only works on the happy path.

EcomTrade24 Pay is built around hosted checkout, payment links, API/webhook automation and Smart Routing for merchants who need more than one fragile payment path.

https://pay.ecomtrade24.com

A Payment Button Is Not a Payment System

EcomTrade24 Pay — Tue, 30 Jun 2026 08:24:26 +0000

A Payment Button Is Not a Payment System

A lot of ecommerce integrations start with one simple goal:

“Add a payment button.”

That sounds reasonable.

The merchant wants to get paid. The developer connects a provider. A checkout URL is created. The customer pays. A webhook updates the order.

Done.

At least, that is how it looks in the happy path.

But in real ecommerce, the happy path is only one part of the system.

Payments fail.

Webhooks arrive late.

Customers abandon 3D Secure.

Providers decline transactions.

Order statuses get stuck.

A payment session expires.

A customer tries again with another method.

The provider says “paid” but the shop never updates.

The shop says “pending” but the customer was already charged.

That is why a payment button is not a payment system.

A payment system needs to handle what happens when things are not perfect.

The happy path is easy

The easiest version of a checkout flow looks like this:

Customer -> Checkout -> Payment Provider -> Success -> Order Paid

For a test transaction, this is usually enough.

But production traffic is different.

A more realistic flow looks like this:

Customer -> Checkout Session Created
         -> Redirected to Hosted Checkout
         -> Chooses Payment Method
         -> Provider Processing
         -> Webhook Sent
         -> Order Status Updated
         -> Customer Redirected

Even this is still too simple.

Because each step can fail or arrive in a different order.

The customer redirect may happen before the webhook.

The webhook may arrive before the customer returns.

The customer may close the browser.

The provider may mark the payment as under review.

The session may expire.

The same webhook may be sent twice.

If the integration is not built for that, the merchant ends up with support tickets.

Webhooks should be treated as the source of truth

A common mistake is relying too much on the redirect URL.

The customer reaches a success page, so the shop marks the order paid.

That is risky.

A redirect tells you that the customer’s browser moved somewhere.

A webhook tells your backend what the payment provider says happened.

The backend should usually treat webhook confirmation as the important event.

A better pattern is:

Customer redirect = user experience
Webhook event     = payment confirmation

The redirect can show a friendly message like:

Thanks, we are confirming your payment.

The webhook should update the order when the final status is known.

Payment statuses need clear rules

Do not build payment handling around only success and failed.

That is not enough.

A practical checkout system usually needs statuses like:

created
pending
paid
failed
expired
cancelled
review
refunded

Not every provider uses the same words, but your internal system should normalize them.

For example:

provider_status: "completed"
internal_status: "paid"

Or:

provider_status: "under_review"
internal_status: "review"

This gives the merchant dashboard and shop plugin a consistent way to understand what happened.

Idempotency matters

Webhooks can be sent more than once.

That is normal.

Your system should be safe if it receives the same webhook multiple times.

Bad pattern:

Webhook received -> Add wallet credit
Webhook received again -> Add wallet credit again

Better pattern:

Webhook received
Check if event/payment already processed

If not processed:
    update order
    create transaction record
    mark event as processed

If already processed:
    ignore safely

A payment confirmation should be repeat-safe.

That one rule prevents a lot of ugly accounting problems.

Store provider references

When creating a payment session, store your own internal ID and the provider’s reference.

Example:

merchant_order_id
payment_session_id
provider_payment_id
customer_email
amount
currency
status
created_at
expires_at

This makes debugging possible later.

When a merchant asks, “What happened to this order?”, you do not want to search through random logs.

You want a clean payment session record.

Checkout expiration should be handled

A hosted checkout session should not live forever.

If a customer opens checkout and never pays, the system needs to know when that session is no longer valid.

That helps with:

Cleaning up pending orders
Showing accurate merchant dashboard data
Preventing old checkout links from being reused
Reducing customer confusion
Avoiding manual support work

An expired session is not the same as a failed payment.

A failed payment means payment was attempted and did not succeed.

An expired session may mean the customer never completed checkout.

Those are different events and should be tracked differently.

Fallback is part of payment infrastructure

A single provider is easy to integrate.

But a single provider can also become a single point of failure.

If the card route fails, what happens next?

Does the customer get another option?

Can the merchant send a payment link?

Can the checkout offer a different method?

Can local methods be shown where available?

Can crypto settlement be used where it makes sense?

Can the system route based on amount, country or method?

This is where Smart Routing becomes useful.

A simplified routing idea could look like this:

if method == "card" and amount >= card_minimum:
    route_to_best_card_provider()
elif method == "bank_transfer" and country_supported:
    route_to_local_bank_method()
elif method == "crypto":
    route_to_crypto_checkout()
else:
    show_available_fallback_methods()

The customer should not see all the complexity.

The merchant should benefit from it.

WooCommerce needs extra care

WooCommerce is flexible, but order status handling needs discipline.

A clean payment plugin should think about:

Creating a payment session from the backend
Never exposing secret API keys in frontend JavaScript
Redirecting the customer to hosted checkout
Listening for webhook confirmation
Updating the WooCommerce order status correctly
Adding order notes for traceability
Handling failed, expired and review events
Avoiding duplicate payment confirmation
Showing useful diagnostics to the merchant

The plugin should not just say “payment failed.”

It should help the merchant understand why the payment failed, where possible.

A useful payment log is not optional

Logs are not glamorous.

But when real money is involved, they matter.

At minimum, a merchant or admin should be able to see:

Session created
Customer redirected
Provider selected
Webhook received
Status changed
Order updated
Error message if something failed

Without this, every issue becomes guesswork.

And guesswork is expensive.

Keep the customer experience simple

More routing behind the scenes should not mean a messy checkout.

The customer should see a clean payment flow.

The system can handle provider selection, fallback rules, limits and settlement logic in the background.

That is the balance:

Simple for the customer
Flexible for the merchant
Traceable for the developer

A good payment system needs all three.

The real checklist

Before calling a payment integration “done”, ask:

What happens if the webhook is delayed?
What happens if the webhook is sent twice?
What happens if the customer closes the browser?
What happens if the payment is under review?
What happens if the session expires?
What happens if the provider declines the transaction?
What happens if the customer wants another method?
What happens if WooCommerce shows pending but the provider says paid?
Can the merchant see a useful log?
Can support understand what happened without asking a developer?

If the answer is “we do not know”, the integration is not finished.

It only handles the happy path.

Final thought

Adding a payment button is easy.

Building a payment system is harder.

The difference is not the first successful test transaction.

The difference is what happens when production traffic gets messy.

That is where good checkout infrastructure matters: hosted checkout, clear webhooks, safe status handling, fallback routes, useful logs and routing logic that helps merchants keep sales moving.

EcomTrade24 Pay is built around that idea for ecommerce merchants, WooCommerce shops and businesses that need more than one fragile payment path.

Learn more about EcomTrade24 Pay for Hosted Checkout, WooCommerce, API/webhook automation and Smart Routing:

https://pay.ecomtrade24.com