Merchant Approved, Campaign Live: Where Are the Transactions?

The merchant is approved. Marketing launches the campaign. But the business cannot see the transactions.

Ad spend is running. Customers are reaching checkout. The team starts asking: “Are payments going through?” “Which orders have been paid?” “Should we keep the campaign running?”

Approval, payment processing and transaction visibility can sit with different teams. Each team may have completed its own task while the purchase journey still has an untested handoff. Credentials, merchant permissions, order updates, notifications and finance reports all need to agree about the same transaction.

This article is a practical review framework for that handoff. The scenarios and test amounts are illustrative, not reports of a real merchant incident. Adapt the cases to the gateway, payment method, API version and operating policy you actually use. A ticked checklist is a record of a review, not a certification or a guarantee.

Illustrative photograph of a team investigating transaction visibility. It does not show a measured payment outcome.

How one purchase should flow

Follow the same order reference through these handoffs. The diagram shows a logical investigation path, not a promise about webhook arrival order or settlement speed.

Merchant approval and configuration

Check the live account, permissions, enabled methods and environment. This is a prerequisite, not proof of a payment.

Customer starts checkout

Confirm the intended purchase

Use the server-calculated amount, currency and intended order reference.

Create one intended payment operation

Persist a durable operation identity

Use the provider’s idempotency contract and application controls to deduplicate repeated requests.

Read authenticated backend evidence

Classify the original payment outcome

Keep authentication, authorization and capture separate. A browser return is not the authoritative outcome.

Alternative outcome: failedSTOP. Do not mark the order paid.

Show the actual result and a traceable reason.

Alternative outcome: unknownInvestigate the original attempt.

Keep the original reference; do not create another charge to repair missing visibility. Once resolved, return to classify the original outcome.

Confirmed under the payment / capture policy only

Order and fulfillment decision

Link the payment to the order. Apply the agreed fulfillment policy once, even when an event is delivered twice.

Expose the same transaction to the business

Merchant and support view

Show the correct account, amount, currency, current state and payment/order references.

Choose the relevant after-purchase path

If a refund is requested

Full or partial refund

Check permission and the remaining refundable amount. Create a separate deduplicated refund operation.

Follow this refund’s own lifecycle

Track the refund outcome

Keep accepted, pending, failed and completed states separate. Request acceptance is not proof that the customer received the credit.

Or: no refund requested

If no refund is requested

Retain the payment record

Keep the original payment and order evidence. Continue with later reconciliation; no refund operation is needed.

Both paths: reconcile actual records, including unresolved items

Later reconciliation

Match payments, refund adjustments and fees to the payout report, then to bank credit. Keep missing evidence and pending items visible.

Failure and unknown results do not flow into fulfillment. Reconciliation is required with or without a refund, and does not promise immediate settlement or customer credit. Release campaign spend only after the relevant end-to-end checks have evidence and a named launch decision owner.

For example, Stripe distinguishes a PaymentIntent's detailed lifecycle from its simplified dashboard grouping. A success screen should therefore not be the only input to a fulfillment decision. Stripe payment status updates

First distinguish failed payments from missing visibility

An empty merchant screen can mean several things. No customer may have attempted payment. Attempts may have failed. Payments may have completed while an order update or dashboard feed failed. The user may also be looking at the wrong merchant account, date range or environment.

Investigate before choosing a remedy. A missing order is not permission to charge the customer again. A blank graph is not proof of a zero completion rate.

Define a completion rate before displaying it: unique confirmed completed payment attempts divided by unique eligible payment attempts in a stated period. Define what counts as completion for the integration. If the denominator is zero or the feed is unavailable, display an appropriate unavailable/no-attempts state. A 0% completion rate requires a known nonzero population with no confirmed completions; a blank dashboard alone does not establish that result.

How to use the test checklist

Download the editable launch test register. Each row starts Not tested. Record the environment, method, API version, actual result, redacted evidence location, named owner and review date. Mark Pass only when the evidence supports the expected result. Use Fail, Blocked or Not applicable with a reason where appropriate.

Run failure injection and synthetic test cases in a sandbox using provider-supported tools. Any live validation needs the provider's and your organization's authorization, transaction limits and cleanup procedure. Test coverage must reflect the actual launch scope; a passing card test says nothing about an untested wallet or bank-transfer flow.

For each case below, keep the input or operation reference, observed response/event history, resulting business record and reviewer decision. Screenshots alone rarely prove that a retry did not create another financial effect.

1. Confirm the merchant can actually operate

Suggested accountable function: Payments operations. Assign a named owner in the register.

Adyen publishes a separate production integration checklist. Use your own provider's current equivalent alongside the account decision; approval alone does not demonstrate that the deployed checkout uses the intended configuration. Adyen go-live checklist

A01. Approved account, wrong environment

• Test: Open the live merchant configuration and compare account, currency, payment methods and credentials with the release configuration. Expected: The intended production account is enabled; no sandbox secret or test endpoint is used.

A02. Business cannot find a payment

• Test: Give an authorized merchant user a known order reference; search in the portal and export the record. Expected: The user finds the correct merchant transaction, time zone, amount, currency and current status.

A03. Permissions are too broad

• Test: Try viewing another merchant and issuing a refund with a view-only role. Expected: Cross-merchant access and unauthorized mutations are denied; permitted roles remain usable.

A04. The wrong version goes live

• Test: Compare deployed checkout, callback URL, webhook subscription and secret version with the signed release record. Expected: Configuration is consistent and secrets stay out of browser bundles and logs.

2. Prove the checkout-to-order journey

Suggested accountable function: Engineering and QA. Assign a named owner in the register.

P01. Successful purchase

• Test: Complete an approved test purchase for each supported method, device and important channel. Expected: One payment is linked to one order; fulfillment follows the agreed payment/capture policy.

P02. Decline or validation failure

• Test: Use documented sandbox scenarios for decline, invalid input and unavailable payment method. Expected: No paid order is created; the customer sees an accurate next step and a traceable reason.

P03. Authentication interruption

• Test: Test challenge success, failure, cancellation, expiry, app switching and a lost browser return. Expected: Backend evidence determines payment status; authentication success alone does not mark the order paid.

P04. Amount changes during checkout

• Test: Change shipping, tax, discount, item quantity or currency before confirming. Expected: Server totals and customer confirmation agree; stale cart values cannot be charged silently.

P05. Provider succeeds but order update fails

• Test: Drop the response or fail the order write after the provider accepts the operation. Expected: The original attempt is recovered; fulfillment or refund follows an explicit decision without another blind payment.

P06. Capture and cancellation

• Test: Where supported, test delayed capture, partial capture, cancellation before capture and capture failure. Expected: Authorization, capture and cancellation stay distinct; unsupported operations are disabled.

3. Test idempotency across real failure points

Suggested accountable function: Payments engineering. Assign a named owner in the register.

I01. Double-click

• Test: Submit the same purchase twice with the same persisted logical operation identity. Expected: Only one intended payment operation and one fulfillment action occur.

I02. Concurrent workers

• Test: Send the same operation concurrently from two workers. Expected: The provider-specific concurrency response is handled; durable merchant constraints prevent duplicate business effects.

I03. Lost response and retry

• Test: Interrupt the connection after submission, then recover using the documented same-key or inquiry path. Expected: The original outcome is resolved without a new charge; an unknown outcome remains visible while unresolved.

I04. Same key, changed request

• Test: Reuse the operation key with a different amount or cart. Expected: The application rejects accidental key reuse; provider behavior matches its documented contract.

I05. Worker restart

• Test: Restart after persisting the operation but before recording the response. Expected: Recovery retains the original key, request fingerprint and provider reference rather than generating a new operation.

I06. Expired key or alternate provider

• Test: Simulate expiry of the documented retention window and a proposed route change. Expected: An unresolved original attempt is reconciled before a new operation; cross-provider protection is not assumed.

An idempotency key protects a supported operation within a particular contract. In Stripe API v1, retries can replay the original response after execution begins, including a saved server error. API v2 handles failed or partially failed work differently. Do not copy retry logic between versions without checking it. Stripe idempotent requests

Adyen scopes keys to a company account; separate regional endpoints do not provide cross-region duplicate detection. Its transient-error response also affects whether the same request may be retried. Record the account, region, API version and retention rule in the test evidence. Keep merchant-side order and fulfillment constraints even when provider idempotency is enabled. Adyen API idempotency

4. Verify notifications and state recovery

Suggested accountable function: Platform engineering. Assign a named owner in the register.

W01. Invalid signature

• Test: Send an altered or unauthenticated notification using the provider test tooling. Expected: The event cannot change a payment or order; rejection evidence is retained without secrets.

W02. Duplicate delivery

• Test: Deliver the same event repeatedly, then different events that refer to the same business outcome. Expected: Both event-level deduplication and business-action constraints prevent repeated fulfillment or accounting effects.

W03. Out-of-order events

• Test: Deliver an older state after a later confirmed state. Expected: Documented state rules prevent regression; conflicts trigger authoritative lookup or owned investigation.

W04. Unavailable endpoint and crash

• Test: Temporarily fail the endpoint and restart a worker after durable receipt. Expected: Redelivery and recovery work within provider rules; acknowledged events are not lost.

W05. Status inquiry unavailable

• Test: Delay notifications and fail a status lookup. Expected: The order stays accurately pending/unknown with bounded follow-up, an owner and a next update time.

Stripe documents duplicate and out-of-order webhook delivery and signature verification. Delivery order is not guaranteed, and the whole-second created timestamp is neither unique nor a reliable tie-breaker. It cannot by itself establish event order or identify duplicate deliveries. Track event identity and apply business-state rules; retrieve the relevant object when evidence conflicts. Treat those as explicit test cases for that integration; check equivalent requirements for other providers. A durable inbox and guarded business transitions are recommended design choices, not a claim of universal exactly-once delivery. Stripe webhook documentation, Stripe Event object

5. Exercise full and partial refunds

Suggested accountable function: Finance and support. Assign a named owner in the register.

R01. Full refund

• Test: Refund an eligible captured payment through the approved role and workflow. Expected: A distinct refund reference links to the original payment; status changes reach support, order and finance views.

R02. First partial refund

• Test: For a synthetic AED 100 captured purchase, request an eligible AED 30 partial refund. Expected: Records show AED 30 refunded and AED 70 remaining refundable, subject to other reserved adjustments.

R03. Additional partial refund

• Test: After the first test completes, request another eligible AED 20 refund. Expected: Cumulative refund is AED 50 and remaining refundable amount is AED 50; each intentional refund has its own operation identity.

R04. Duplicate refund request

• Test: Retry the same partial refund after losing the response, using the original refund identity. Expected: The retry does not create another refund or reduce the remaining amount twice.

R05. Concurrent or excessive refunds

• Test: Submit concurrent refunds whose combined amount exceeds the remaining refundable balance. Expected: A durable reservation/constraint prevents over-refund; pending refunds count against available refund capacity.

R06. Invalid refund input

• Test: Try zero, negative, excessive precision, wrong currency and amounts above the permitted balance. Expected: Validation matches method/currency rules; money arithmetic uses appropriate exact units, not binary floating-point totals.

R07. Refund pending, failed or reversed

• Test: Use supported test events to exercise non-final and unsuccessful outcomes. Expected: Customer wording matches the evidence; failures are owned and not blindly resubmitted.

R08. Refund conflicts with dispute or cancellation

• Test: Open the relevant sandbox lifecycle scenario before a refund attempt. Expected: The system checks eligibility and overlapping adjustments; operations follows the documented exception path.

Refund eligibility and finality depend on the payment method and provider. Stripe supports full and partial refund workflows. For Adyen, a successful REFUND event confirms validation and submission to the card scheme; a later REFUND_FAILED event is still possible. REFUNDED_REVERSED describes a different outcome in which funds return to Adyen. Keep request acceptance, provider processing and customer credit distinct. The AED examples assume an otherwise eligible, undisputed captured payment; they exclude fees and other adjustments. Stripe refund guidance · Adyen refund lifecycle

6. Reconcile money and enable support

Suggested accountable function: Finance and operations. Assign a named owner in the register.

Adyen separates transaction-level reconciliation from matching payout batches to bank statements. This is one provider example of why a sales total and a bank credit need an explained bridge. Adyen settlement reconciliation

F01. Payout does not equal sales

• Test: Match synthetic payments, refunds, fees, reserves and adjustments to a settlement report and bank credit. Expected: Each difference has a documented component or an assigned exception; no fabricated balancing entry is used.

F02. Missing or duplicate report line

• Test: Remove and duplicate a row in an approved test dataset. Expected: The reconciliation identifies the break; imports and journal posting do not duplicate financial effects.

F03. Support handoff

• Test: Ask a support colleague to investigate a payment using only an order reference. Expected: They can find the payment, capture/refund history, safe provider references and escalation owner.

F04. Customer refund question

• Test: Rehearse an accepted refund that is not yet visible at the customer bank. Expected: Support explains the observed stage and available trace reference without promising an unsupported credit date.

7. Release campaign spend in controlled stages

Suggested accountable function: Launch owner and marketing. Assign a named owner in the register.

L01. Misleading conversion dashboard

• Test: Compare checkout sessions, unique payment attempts, confirmed completions and order records for the same time window. Expected: Denominators and freshness are visible; missing telemetry is shown as unavailable rather than a manufactured 0%.

L02. Campaign traffic spike

• Test: Load-test within the agreed sandbox limits and rehearse throttling. Expected: Capacity limits, queues, timeouts and rate-limit responses are understood; unknown results do not trigger duplicate retries.

L03. Incident during campaign

• Test: Rehearse a material payment failure or unexplained visibility gap. Expected: A named person can cap/pause campaign spend, page the right team and communicate the next update.

L04. Controlled live validation

• Test: If provider and internal policies permit, run authorized limited live validation with documented limits and cleanup. Expected: Real configuration, merchant visibility and follow-up reconciliation are checked; synthetic failure tests stay in sandbox.

L05. Go/no-go decision

• Test: Review all applicable cases with payments, engineering, QA, support, finance and marketing. Expected: Release blockers are closed; exclusions have reasons and an owner; any limited launch has explicit spend and stop conditions.

Decide what blocks the launch

I would treat an unexplained payment outcome, an uncontrolled duplicate-charge path, invalid refund accounting, missing merchant visibility or unavailable incident ownership as a reason to hold the affected launch scope. A limited release may be possible for a separately tested method or channel, but the exclusion must be real in product configuration and customer communication.

Use three decision states: hold, limited launch, and ready for the approved scope. A limited launch needs a traffic/spend cap, a named on-call owner, explicit stop conditions and a scheduled review. There is no universal threshold in this article: define thresholds against your traffic, monitoring delay and risk appetite.

First payout reconciliation may occur after the technical launch window. If it has not happened yet, record it as outstanding, demonstrate the report-to-bank process with test evidence and state who will verify the first actual payout. Do not mark a future event complete to make the checklist green.

Keep a short release record containing the deployment/configuration version, supported methods, completed test cases, exceptions, owners, decision, time and rollback/pause procedure. Repeat affected tests after a material change to credentials, routing, callback handling, order state or refund logic.

What marketing needs before pressing launch

Marketing should know which journeys are cleared for traffic, where payment completion is measured, how fresh that measurement is and who can stop spend. Payments and engineering should know when the campaign begins and what traffic has been agreed. Support and finance need access before the first customer asks for help.

The useful handover is a demonstration: one purchase can be followed from checkout to payment, order, merchant view and eventual reconciliation. Then demonstrate how the team handles a failure and a refund. This makes the remaining gaps visible while the team can still choose how to launch.

For deeper technical detail, read payment status, async updates and idempotency. For the financial end of the journey, see reconciliation as product infrastructure.

Questions teams ask at launch

Does merchant approval mean checkout is production-ready? No. Approval confirms the provider's relevant account decision. Production configuration, integration behavior, permissions and operating readiness still need their own evidence.

Can a success page replace a backend payment check? No. A browser return can be lost or misleading. Use the provider's authenticated result and your documented order/capture policy to decide the business action.

Can every failed refund be retried automatically? No. First establish whether the original refund was accepted, pending, failed or reversed and follow the applicable recovery rules. Retrying an unknown result with a new identity can repeat the operation.

How many boxes must be checked? Every applicable requirement needs a disposition and evidence. Not applicable needs a reason. Unresolved critical cases block the affected scope; a percentage score must not conceal them.