Before Black Friday, checking whether checkout can approve a purchase is not enough. You need to test whether the operation remains correct when many orders arrive, a response is delayed, or confirmation appears after the customer closes the page. Preparation should produce evidence of capacity, recovery, and financial consistency—not just a success screen.
This guide proposes a plan for turning that preparation into verifiable tests. The goal is to answer three questions: can the system handle the planned demand? Does the team know what to do when a dependency fails? And does each order remain associated with the money that actually moved?
The scenarios and acceptance criteria below are architectural recommendations. They should be adapted to each provider's contract, the enabled methods, and business policy. The numerical examples are fictional; they do not represent AZPay results, limits, or guarantees.
What does being ready for peak payment demand mean?
A prepared operation can demonstrate expected behavior in four situations: normal flow, concentrated demand, dependency failure, and subsequent recovery. Each should have a verifiable outcome, an owner, and an investigation path. Availability matters, but it does not remove the need to avoid financial decisions based on incomplete information.
Stripe's guide for the 2026 season, based on transactions the company itself observed in 2025, highlights the importance of testing flows before purchases surge. It is a planning reference, not a traffic forecast for Brazil or a particular store. Source: preparing for the 2026 shopping season, Stripe (opens in a new tab ↗).
AZPay's proposal in this article is to translate that problem into operational evidence. Instead of signing off on a task called “test payments,” record which scenario was run, in which environment, with which version, what the outcome was, and where the evidence is stored. An unexpected result needs an owner and a decision: fix it, restrict the scope, or knowingly accept the risk.
“It worked in testing” is insufficient when no one can reproduce the test or explain what counted as success.
Start with the path from order to confirmation
Map the flow that exists in your operation, not the provider's ideal diagram. Identify who calculates the final amount, who maintains the order, who initiates payment, who authenticates the customer, and who authorizes product release. Include status queries, asynchronous notifications, and the process that checks discrepancies afterward.
Use a test order to walk through that path. Can customer support locate it? Can engineering find the corresponding attempts? Can finance distinguish approval from the subsequent movement of funds? These are proposed rehearsal criteria, not capabilities that should be assumed to exist in every integration.
AZPay's documentation describes the charge webhook as a notification with essential fields, including charge_uuid and status, followed by the ability to retrieve charge details through the API. That separation provides a concrete point for testing the integration: receiving a notification should not be confused with having reconstructed the order's full financial state. See the charge webhooks section in AZPay's Dev Central.
The exercise should show how your application connects that information. Do not copy state names from one method to another without checking the contract. The discussion of payment transaction states helps distinguish authorization, capture, and subsequent operations.
How much load should you simulate?
Start with a demand hypothesis based on your history, campaign, and expected traffic distribution. Record initiated orders, payment attempts, and technical calls separately. Do not use total daily sales alone as a capacity criterion: the test also needs to consider how that volume concentrates over time.
Consider a wholly fictional example. A campaign projects 12,000 payment starts in ten minutes. That corresponds to an average of 20 starts per second over that window. If the test scenario assumes four internal calls per start, that part of the flow will generate 80 calls per second, before additional queries and later events. These numbers describe the test hypothesis, not the capacity every business needs.
Run a gradual ramp-up, a sudden influx of orders, and a sustained period of activity. During recovery, keep new purchases coming while the system processes its backlog. The purpose is to observe not just when the operation deteriorates, but whether it can return to a stable condition.
Include what the simulator does not represent in the report. A test without interactive authentication, a realistic latency profile, or asynchronous events covers only part of the journey. This limitation does not invalidate the result; it simply prevents it from being presented as proof of the complete flow.
Where can you test without creating improper charges or traffic?
Separate tests into three layers: application behavior with simulated dependencies, functional integration in the provider's test environment, and controlled production checks when necessary and authorized. Load testing the store's system does not authorize stress testing third-party APIs.
Stripe itself warns that its sandbox does not fully reproduce production conditions and advises against using it as a load-testing target. It recommends simulating external calls with a representative latency profile. Each provider's limits and testing conditions must be checked directly. Source: API limits and load testing, Stripe (opens in a new tab ↗).
For this plan, define scope, duration, volume, synthetic data, and stop conditions. Use only authorized test credentials and instruments. When a real financial check is needed, agree on amounts, owners, and subsequent handling in advance, without turning it into a large-scale test.
The report should clearly distinguish what was simulated, what went through the sandbox, and what was validated in the live environment. Mixing those evidence types creates confidence the test did not establish.
Test 1: does checkout preserve the order when the journey is interrupted?
Run the flow on mobile and desktop, including switching apps to pay, refreshing the page, temporarily losing connectivity, and returning to the order. Also check keyboard use and message readability. The question is not just whether the button appears, but whether the buyer can understand the purchase state and continue without accidentally creating a new intent.
During the test, check the server-calculated amount after coupons, shipping, and installment selection. The screen, order, and payment request should reflect the same commercial decision. A legitimate cart change needs the expected handling, not a silent charge for an amount different from the one the customer confirmed.
Proposed acceptance criterion: interrupting and resuming the interface does not change the approved amount or create a second order without explicit intent. The customer can find the previous purchase and receives guidance consistent with the state known to the backend.
Record screenshots without sensitive data and the synthetic identifiers used in the test. The comparison between embedded checkout and hosted checkout can help identify which parts of this behavior belong to the store and which depend on the provider.
Test 2: what happens when the PSP response never arrives?
Simulate an operation received by the provider whose response does not return to the application. Then have a query or asynchronous notification report the result. This case differs from a failure known to have occurred before submission.
Stripe's error-handling documentation explicitly states that a communication failure can leave an operation's outcome unknown. It also advises resolving that uncertainty before starting another operation with a new key. This is a reference to a specific contract, not a universal rule for every PSP. Source: low-level error handling, Stripe (opens in a new tab ↗).
For your application test, require a recognizable intermediate state. The screen should not say “declined” just because the waiting period ended. Support also needs to see that an attempt is awaiting confirmation, avoiding advice to make a new purchase as though failure were certain.
Proposed acceptance criterion: late information is correlated with the correct attempt; no uncontrolled second charge appears; and the operation ends with a known outcome or an exception assigned to someone. Define an investigation window appropriate to the contract without inventing a universal waiting period.
The deeper discussion of payment timeouts covers the differences between the interface deadline and the financial lifecycle.
Test 3: do repeated requests produce only the intended effect?
Resend the same operation under controlled conditions: double-clicking, HTTP client retries, process restart, and concurrent calls. Also run a negative test with the same operation identity and incompatible parameters. The system should recognize legitimate repetition without confusing it with a new commercial obligation.
Adyen documents idempotency for its API calls, including scope and limitations across regional endpoints. This illustrates why the guarantee must be read in the provider's contract rather than assumed from the presence of a field called “key.” Source: API idempotency, Adyen (opens in a new tab ↗).
In your test, track the order identity, intended operation, and its attempts. A new installment, a capture, and a refund should not indiscriminately share an identity just because they belong to the same order. Each operation needs a scope corresponding to its effect.
Proposed acceptance criterion: technical repetition preserves the permitted financial effect; an incompatible request does not silently reuse a previous result; and restarting the application does not erase the controls needed to recognize the operation.
Include product release in the test. Protecting the PSP call while shipping twice would still be an incorrect business outcome.
Test 4: does recovery increase load on the degraded component?
Simulate a slow dependency and observe the combined behavior of the browser, application, background processes, and HTTP clients. Record how many additional attempts appear. The goal is to discover whether different layers repeat the same work without coordination.
The AWS Builders' Library explains that retries can amplify overload and recommends careful decisions about timeouts, progressive waiting, and interval variation. For operations with side effects, the safety of repetition remains a separate issue. Source: timeouts, retries, and backoff with jitter, AWS (opens in a new tab ↗).
For the test, establish explicit concurrency and retry limits appropriate to the integration. Check what happens when the limit is reached: is there a comprehensible message? Is the work preserved? Can you investigate what did not progress?
Proposed acceptance criterion: the system reduces pressure on the degraded dependency and maintains traceability for pending operations. Recovery should be observed while new purchases arrive, not just after artificially stopping all demand.
Waiting longer between attempts does not make a duplicate charge safe. First determine whether repetition is permitted; then control its frequency.
Test 5: does the alternative route work for that transaction?
When more than one PSP is available, test the alternative with the methods, currencies, and credentials actually used by the operation. Include the authentication path where applicable. Checking that the second integration responds to an isolated call is not enough.
Run two separate tests. In the first, prevent a new intent from being sent to the unavailable route and check the eligible alternative. In the second, leave an earlier attempt without a conclusive result. In that second case, the goal is not to require automatic switching, but to demonstrate that the policy handles uncertainty before risking another financial effect.
Proposed acceptance criterion: the chosen route is technically usable for that context, the decision can be explained, and previous attempts remain monitored. A credential available at only one provider should appear as a limitation of the plan, not disappear from the report.
Do not use Black Friday as a reason to put a newly connected integration into service without this test. An alternative that has not yet been validated should be described as pending work. The guide to payment failover explores why redundancy depends on state control.
Test 6: do webhooks remain correct when they arrive outside the ideal flow?
Prepare repeated, delayed, and out-of-order deliveries. Stop the consumer, then restart processing. Include a situation where the notification arrives before the application finishes handling the synchronous response.
Adyen's guidance for consuming webhooks separates authenticity verification, storage, receipt acknowledgment, and business logic processing. This sequence helps distinguish “the message was received” from “the order was processed.” Source: handling webhook events, Adyen (opens in a new tab ↗).
Proposed acceptance criterion: the application acknowledges receipt only after durably preserving the message according to the adopted design and contract. A restart must not silently remove already acknowledged work. Repeated events must not release products again, and an older update must not overwrite more recent information without validation.
Also test two legitimate changes to the same charge. Deduplicating everything solely by the charge identifier can prevent a later event from being applied. The domain model needs to distinguish the financial entity from each relevant update.
For authenticity, follow the mechanism actually offered by the provider. Adyen, for example, documents access controls and integrity verification for its notifications; a header or algorithm should not be generalized to all providers. Source: webhook security, Adyen (opens in a new tab ↗).
The article on payment webhooks provides additional context for these decisions.
Test 7: is Pix confirmed without relying on the browser's return?
Generate a test charge, display the QR code, and complete the journey supported by the authorized environment. Close the page before confirmation and check whether the backend can still recognize receipt and associate it with the order. Then test the interface update when the buyer returns.
The Pix API maintained by Brazil's Central Bank distinguishes charge resources, received Pix payments, refunds, and notifications. This separation matters to the integration model: the charge representation and information about receipt play different roles. Source: official Pix API repository, Banco Central (opens in a new tab ↗).
In the proposed test, check the identifiers provided under the contract being used, the received amount, and the commercial reference. Do not mark the order as paid just because the QR code was displayed or the customer showed a payment receipt screen.
Include a receipt that reaches the system after the commercial order has expired. Do not try to demonstrate that every expired charge remains payable; behavior depends on the flow. The scenario tests how the store handles a late confirmation relative to its own reservation deadline.
Proposed acceptance criterion: the money is recognized, the discrepancy is traceable, and business policy determines the next step. Reopening the order, handling an exception, or returning the amount are decisions that need rules, not improvisation by a support agent. See also Pix charges, confirmation, and refunds.
Test 8: are authentication and risk handled as different stages?
Exercise supported authentication scenarios: completion without an interactive challenge, completed challenge, abandonment, and technical failure. On mobile, test switching to the authentication app and returning to the purchase. Record the stage at which each attempt ended.
EMVCo describes a challenge as a flow in which the issuer may request additional checks to complete authentication. The result of this stage should not be confused with the subsequent financial authorization decision. Source: how the EMV 3DS challenge works, EMVCo (opens in a new tab ↗).
For risk, propose synthetic cases approved by the responsible team and verify that the application correctly executes each decision received. The test should evaluate the integration and messaging without publicly exposing rules, sensitive signals, or internal thresholds.
Proposed acceptance criterion: risk blocks, incomplete authentication, authorization declines, and technical failures appear as distinct situations in the operation. The buyer receives the next permitted action without information that reveals detection logic.
Do not suspend controls just because an aggregate metric fell. This plan recommends first investigating the affected stage, comparing equivalent populations, and discussing any change with the risk owner.
For a deeper analysis of risk blocks and legitimate sales during the campaign, see Fraud prevention before Black Friday: how to investigate blocked legitimate purchases.
Test 9: do authorization, capture, and refunds remain traceable?
When the integration separates authorization and capture, test both operations individually. Include late capture within the permitted window, cancellation before capture, and an inconclusive response. Also exercise recovery of subsequent information, not just the first call.
For refunds, test repeated requests, partial amounts where supported, and concurrency between two support actions. Adyen's documentation illustrates amount controls for captures and refunds on its own platform; your integration should follow the corresponding contract and also maintain consistency in local records. Source: idempotency and modification limits, Adyen (opens in a new tab ↗).
Proposed acceptance criterion: every subsequent operation points to the correct transaction, preserves its identity, and appears in the financial history. A submitted request is not presented as confirmed completion without the evidence required by the flow.
Have support walk through the scenario with engineering. The operator should be able to distinguish “order canceled” from “amount refunded,” identify operations still processing, and avoid opening a second request because of missing visibility.
The test ends only when the team can explain the synthetic case's balance, including temporary differences that are still expected.
Which metrics should you track during tests and the campaign?
Separate technical health, journey progress, and financial outcome. For technical health, observe volume, errors, latency, and critical resource utilization. For the journey, track where the customer interrupts or completes each stage. For finance, maintain visibility into confirmed operations and exceptions still needing resolution.
Google's SRE book proposes latency, traffic, errors, and saturation as fundamental monitoring signals. Applying them to the payment flow in this plan adds business questions: which orders were affected, which attempts remain uncertain, and which amount still needs reconciliation. Source: monitoring distributed systems, Google SRE (opens in a new tab ↗).
Define denominators before the campaign. “Approval per attempt,” “paid orders,” and “checkout conversion” should not be displayed as if they answer the same question. Also record the observation window: a Pix payment still awaiting payment is not necessarily a technical failure.
For latency, observe the distribution and tail, not just the average. For queues, consider tracking depth and the age of the oldest item. For alerts, combine a relevant condition, a minimum volume where necessary, and an expected action. Trigger values should come from the operation, not a universal number published in a blog.
Keep investigation identifiers in appropriate, controlled records instead of indiscriminately turning them into dimensions of every metric. Do not put credentials or complete payment data in logs to make diagnosis easier.
The guides to payment observability and approval rates explore this separation further.
Run a rehearsal that ends with recovery, not an alert
Choose a synthetic incident and walk through the full response. For example: a dependency slows down; some attempts remain inconclusive; notifications accumulate; the team applies the planned mitigation; service returns; and reconciliation identifies what still needs attention.
In this exercise, the clock is there to observe the process, not to meet an invented target. Record when the problem was noticed, when someone took coordination ownership, which hypothesis guided the action, and when evidence of recovery appeared.
Define roles before the rehearsal: incident coordination, technical investigation, provider contact, support communication, and financial follow-up. On small teams, one person may hold several roles, but every responsibility needs to be explicit.
Proposed acceptance criterion: mitigation does not lose operations already started; support receives consistent guidance; and inconclusive cases remain traceable until closure. A restored success rate does not automatically resolve all outstanding financial issues.
At the end, turn the results into concrete procedural changes. A rehearsal that produces only a meeting, without fixing an observed gap, has not yet fulfilled its preparation role.
How should you organize work before Black Friday?
Use your campaign calendar as the reference and reserve time to fix issues and repeat tests. The schedule below is an organizational proposal, not a technical requirement or regulatory deadline.
Between six and four weeks before the expected peak, map dependencies, review history, and agree on testing conditions with partners. Define what will be measured and the mandatory scenarios. Confirm which methods, integrations, and changes will actually be available.
Between four and two weeks beforehand, run functional, load, and failure tests. Resolve issues affecting financial state, recovery, and experience. Repeat corrected scenarios, preserving evidence from the new version.
In the final two weeks, focus on operational rehearsal, contacts, observability, and checking the rollback plan. Restrict high-risk changes under the team's policy without preventing necessary security or reliability fixes.
During the campaign, monitor behavior by segment and record configuration changes. After the peak, maintain routines for resolving exceptions, refunds, and reconciliation. Financial work does not end when traffic returns to normal.
What should block the campaign launch?
A launch decision needs to distinguish a known limitation from a failure that could produce an incorrect financial effect. For this plan, establish an approval gate with scenario-specific evidence, an owner, and a recorded decision.
Consistency blockers include a retry that creates an improper charge, a confirmation that releases the wrong order, an acknowledged notification lost on restart, and an interface that encourages a new payment while the first attempt remains inconclusive. Each requires correction or explicit restriction of the affected flow before release.
Operational blockers include a contingency route that has never been exercised, no owner for pending cases, and an inability to locate cases affected by an incident. Do not treat a diagrammed architecture as equivalent to demonstrated recovery.
Approval should show the set of capabilities permitted at launch. An operation may choose fewer methods or less automation, provided the scope is clear and consistent. Adding complexity without evidence is not a prerequisite for readiness.
How does this plan connect to an AZPay integration?
In the integration described by AZPay's documentation, a charge has its own identity, changes can be notified through a webhook, and details can be retrieved through the API. Use those contracts to design the test between your application and the payment layer. The test should prove how your order is correlated with the charge and how an update becomes a permitted commercial action. Start with AZPay's Dev Central.
That does not mean AZPay automatically offers every mechanism described in this guide. Retry policies, route availability, authentication, capture, and operational handling depend on enabled capabilities and the integration's actual design. Confirm that scope before turning an architectural recommendation into a product requirement.
This plan contributes a way to build and assess the operation: require identity, evidence, and ownership at every transition. The expected benefit is not a promise to approve every purchase, but fewer decisions made without knowing what happened.
For a deeper architectural view, see the guide to payment orchestration. When preparing your integration, check every scenario against AZPay's current documentation and the contracts of the providers involved.
Black Friday tests more than the ability to approve payments
A campaign puts pressure on the entire path from purchase intent to financial closure. A useful test does not end with an API response: it follows the message shown to the customer, the order update, later events, and the team's ability to resolve exceptions.
That is why “checkout worked” should be replaced with specific evidence. Which scenario was run? What was confirmed? What remained unknown? Who took ownership? Which behavior needs to be corrected before launch?
From AZPay's builder perspective, preparing payments means making these answers part of the operation. Before the peak, rehearse failure. During the peak, decide based on evidence. Afterward, close outstanding cases with traceability. The guide to payment reconciliation is the next step in understanding that closure.
About the references and technical review
External sources are identified alongside the corresponding claims. The test recommendations, acceptance criteria, schedule, and sizing example are editorial proposals, not reproductions of a standard or reports of customer results. Provider documentation should be rechecked before implementation because contracts and capabilities may change.
The AZPay reference used is Dev Central's charge webhook documentation, especially the distinction between a notification and a details query. Simplified integration examples do not replace durable persistence, handling multiple events, and production security validation. References reviewed for the October 2026 edition.