Skip to content
MaxoPerf MaxoPerf docs

Third-party and payment dependencies

Your checkout journey reaches past your own servers. A typical e-commerce platform calls 8–12 external services on every completed order: payment gateway, fraud detection, inventory reservation, tax calculation, shipping rate lookup, loyalty points, email confirmation, analytics. Under BFCM load, any one of them can become the bottleneck, or hit a rate limit that sets off failures across your own checkout flow.

You test these dependencies differently from your own services.

The dependency landscape

Section titled “The dependency landscape”
Dependency typeExamplesRisk under BFCM load
Payment gatewayStripe, Braintree, Adyen, PayPalRate limits per account; high-load latency increase; auth token expiry
Fraud detectionSignifyd, Kount, ForterTimeout increases under load; decision latency affects checkout UX
Inventory reservationInternal or third-party WMSConcurrent inventory updates cause lock contention; oversell risk
Tax calculationAvalara, TaxJarAPI rate limits; response time increases; sandbox quota different from production
Shipping ratesFedEx, UPS, DHL APIsThird-party rate limits; latency variance
Email / notificationsSendGrid, MailgunDelivery queue saturation; bounce-back storms
Loyalty / pointsInternal or third-partyConsistency requirements; synchronous writes slow checkout
Analytics eventsSegment, AmplitudeUsually fire-and-forget; can cause memory pressure if not bounded

The fundamental rule: do not DoS your partners

Section titled “The fundamental rule: do not DoS your partners”

Before you run a load test that calls real third-party APIs, read the provider’s terms of service on load testing. Many payment processors and SaaS APIs forbid load testing against their production or sandbox environments without prior written authorization. Break that rule and the provider can suspend your account, right when you need it most.

Authorized testing is required. If a MaxoPerf load test will send synthetic traffic to a real payment processor, tax provider or other third-party API, get written authorization from the provider first. This is not optional.

For most third-party dependencies, the practical BFCM answer is to mock the dependency at the network level. Test the integration points separately with lower-volume authorized tests.

Mocking strategy

Section titled “Mocking strategy”
Section titled “Option 1: API mock server (recommended for most dependencies)”

Run a lightweight mock server in your staging environment. It returns realistic responses with realistic latency variance, and it should simulate:

  • Happy path responses (90 % of calls): realistic response body, 200–400 ms latency
  • Rate limit responses (5 % of calls): HTTP 429 with Retry-After header
  • Timeout responses (2 % of calls): no response for 10–30 seconds, then connection close
  • Error responses (3 % of calls): HTTP 500 or 503 with error body
# Taurus scenario targeting your staging environment
# which internally calls the mock server, not the real gateway
scenarios:
  bfcm-checkout-with-mocked-payment:
    requests:
      - url: https://api.staging.example.com/v1/checkout/payment
        label: POST /checkout/payment
        method: POST
        headers:
          Content-Type: application/json
          Authorization: Bearer ${SESSION_TOKEN}
        body: '{"payment_method": "card", "token": "tok_test_${PAYMENT_IDX}"}'
        # The staging checkout service calls the mock payment gateway internally
        # No direct call to the real payment processor from the load runner

In this setup, your staging checkout service calls the mock payment gateway. The MaxoPerf runner calls only your own checkout API. The mock is behind your own network boundary.

Option 2: Sandbox environment (authorized, limited volume)

Section titled “Option 2: Sandbox environment (authorized, limited volume)”

If a third party provides a sandbox and permits load testing (confirm in writing), you can run a lower-volume targeted test directly against the sandbox. Limit to 10 %–20 % of your expected peak call volume per minute, and run during off-peak hours for the provider.

Option 3: Feature flag / bypass

Section titled “Option 3: Feature flag / bypass”

Some payment gateways offer a test mode that skips actual processing. Use your application’s existing test/sandbox mode for checkout and load test with test payment tokens. This does not check gateway latency under load. It does check your application logic without calling the real gateway.

Testing rate limit handling

Section titled “Testing rate limit handling”

BFCM is when you are most likely to hit payment processor rate limits. Your per-account transaction rate is set for normal volume, and BFCM can exceed it. Test how your application behaves when the gateway returns HTTP 429:

  1. Configure your mock to return 429 on 10 % of payment requests.
  2. Run a load test at peak VU count.
  3. Check three things. Does your checkout service retry correctly? Does it show the user an error, or drop the request silently? Does the retry loop cause a thundering herd that makes 429s more frequent?

Correct behavior: exponential backoff with jitter on retries, a user-facing message like “payment is busy, please wait,” and no failure spreading into the rest of checkout.

Inventory reservation under concurrent load

Section titled “Inventory reservation under concurrent load”

The inventory reservation race is a classic BFCM problem: 500 users try to reserve the last 10 units of a doorbuster item at the same moment. Most systems handle this badly. They either oversell (every reservation succeeds, and orders get cancelled later) or deadlock (all reservations time out).

Test it directly:

scenarios:
  inventory-contention:
    requests:
      - url: https://api.staging.example.com/v1/inventory/reserve
        label: POST /inventory/reserve
        method: POST
        headers:
          Content-Type: application/json
        body: '{"product_id": "limited-sku-001", "qty": 1}'

Run 200–500 concurrent VUs against the same limited-inventory SKU. Check that:

  • The total number of successful reservations matches available inventory exactly (no oversell)
  • Failed reservations return a clean 409 Conflict with an informative message (not 500)
  • Response time for the reservation endpoint stays below 2 seconds even under contention

Dependency failure modes and circuit breakers

Section titled “Dependency failure modes and circuit breakers”

BFCM preparation is also when you test what happens when a dependency goes down. Use MaxoPerf together with your staging environment’s chaos/fault injection tooling:

  1. Start a peak-load test against the full checkout funnel.
  2. After 5 minutes of stable load, have the ops team disable the tax calculation service.
  3. Watch what checkout does. It should fall back cleanly (skip tax, apply a cached rate, or decline cleanly). The bad outcome is checkout hanging on the tax response until the 30-second timeout fires.

This confirms that your circuit breakers, timeouts and fallback paths work under load, and not only in unit tests.

Where to go next

Section titled “Where to go next”