Payment Gateway Testing in 2026: The Reliability Playbook

Why Fora Soft wrote this playbook

Fora Soft has shipped payment integrations since 2005, across 250+ projects and every vertical we build in: SaaS subscriptions, e-learning seat billing on BrainCert, telemedicine copays on CirrusMED, premium streaming on Worldcast Live, trading flows on TradeCaster. Every one of those products moves real money, and every one has had to survive a gateway hiccup, a webhook storm, a card-network change or a regional compliance update.

This is the method our QA team, engineers and delivery leads actually use when we design, test and operate payments for clients. Nothing aspirational — the exact metrics, thresholds, patterns and anti-patterns we hold ourselves to on every release. It is also how we approach custom software development in general: measure first, build the boring reliability layer, then prove it in production.

Read it end to end once. After that, keep it open when a gateway outage hits, or when the CFO asks why 8% of cards are declining and nobody can answer. If you want the same pipeline installed on your codebase, we ship it as a fixed-scope 3–6-week engagement.

Why payments break differently from other features

A feature bug frustrates users. A payment bug charges them twice, grants access without a charge, or locks them out of a paid product mid-session. Payments sit in the narrow band of the codebase where a technical error turns into direct financial liability.

Money and access must match. Every successful authorization has to grant access. Every revoke has to take it away. Any drift between the provider’s state and your application’s state is a bug with a customer-support cost stapled to it.

Failures multiply. A single retry storm against a degraded gateway becomes thousands of duplicate charges. A single missed webhook becomes a subscription that never starts, a customer who cancels, a support ticket, a chargeback, and a hole in customer lifetime value.

Edge cases are statistical certainties. At 100,000 transactions a month, the 0.01% edge case ships ten production incidents. Your test plan has to cover currencies, 3DS cancellations, network timeouts, gateway 5xx responses, webhook duplication, webhook reordering and partial refunds — or production finds them for you.

The seven reliability metrics that matter

Pick these seven, surface them on one dashboard, alert on each. Everything else is debugging context.

1. Authorization rate. Successful auths divided by attempted auths. The card-not-present industry average sits near 87%; best-in-class SaaS lands 96–98% (Gr4vy payment benchmarks, 2026). Every point is real revenue — a 1% lift on $10M GMV is $100K a year.

2. Decline rate. Declined auths over attempted auths. Under 3% for B2B SaaS, 10–15% for B2C consumer goods, 1–2% best-in-class. Segment by issuer country and card brand or the average hides the real pattern.

3. False-decline rate. Legitimate customers blocked by fraud rules. Target under 2%, best-in-class under 0.5%. False declines cost US merchants an estimated $157B a year (Javelin, 2023) — more than three times actual card fraud, and about a third of blocked shoppers never come back.

4. 3DS success rate. Of transactions that entered a 3DS challenge, how many completed. Around 81% industry average, 85%+ if you tune exemption logic. Below 75% and your 3DS flow is broken or mobile rendering is failing.

5. Chargeback rate. Chargebacks over transaction volume. Under 0.5% is healthy; cross 0.9–1% and you enter Visa and Mastercard monitoring programs; past 1.5% you risk your merchant account. Segment by reason code: fraud versus non-fraud need different fixes.

6. Auth latency (p99). Time from authorization request to response. Target under 250 ms p99, best-in-class under 150 ms. Above 500 ms, users abandon carts and retry storms start on timeouts.

7. Webhook latency (p95). Time from gateway event emission to your handler acknowledgement. Target under 5 s, best-in-class under 1 s. Slow webhooks mean subscriptions activate late, access is granted late, and racing writes corrupt state.

Red, yellow, green thresholds per metric

Here are the alert bands we wire into the dashboard. Green is healthy, yellow warns, red pages the on-call engineer.

Figure 1. The seven-metric scorecard we alert on — each metric fires independently so a regional failure isn’t hidden by a healthy global average.

Architecture: adapter, outbox, saga

Four patterns do the heavy lifting on every payment system we ship. Get them in place and most of the incident classes above simply can’t happen.

Figure 2. How one charge flows through the four patterns — the provider adapter, saga orchestrator, webhook worker and transactional outbox — with every stage feeding one observability dashboard.

1. Provider adapter (abstraction layer)

Your business logic never imports Stripe or Adyen SDKs directly. Everything goes through a PaymentProvider interface with 8–12 methods (authorize, capture, refund, void, createCustomer, createSubscription…). Implementations live in separate files per gateway. Swapping Stripe for Adyen becomes a config change plus tests, not a rewrite.

2. Idempotency keys

Every charge attempt carries a UUID generated on the client before the first call. The server stores the key in a dedicated payment_attempts inbox table. A replay with the same key returns the cached result. Stripe, Adyen and Braintree all honor an Idempotency-Key header natively — reuse theirs, don’t reinvent it.

3. Transactional outbox

Domain write and event emission must be atomic. Inside the same database transaction you update subscriptions.status and insert a row into an outbox table. A background relay publishes pending rows to your event bus and marks them processed. The result: no lost events, no orphan state, 10–50 ms of added latency.

4. Saga orchestration

Multi-step flows (authorize → 3DS → capture → grant access → reserve inventory) run as an explicit state machine with a compensating action for every step. Temporal, Restate, or a hand-rolled machine on top of your database. Each step is idempotent. A partial failure rolls back cleanly instead of leaving the customer charged with no access.

// charge.saga.ts — minimal skeleton
export async function chargeSaga(order: Order, key: IdemKey) {
  const auth = await withRetry(() =>
    gateway.authorize({ amount: order.total, idempotencyKey: key + ':authorize' })
  );
  let capture;
  try {                                  // pre-capture failure => nothing charged yet
    if (auth.requires3DS) await wait3DS(auth);
    capture = await gateway.capture(auth.id, key + ':capture');
  } catch (err) {
    await gateway.void(auth.id, key + ':void');          // void the authorization
    throw err;
  }
  try {                                  // money moved: on failure, refund (never void)
    await db.tx(async t => {
      await t.orders.markPaid(order.id, capture.id);
      await t.outbox.insert({ type: 'order.paid', id: order.id });
    });
  } catch (err) {
    await gateway.refund(capture.id, key + ':refund');   // captured but not recorded
    throw err;
  }
  return capture;
}

Idempotency keys: the single biggest win

Of every payment incident we’ve triaged in 20 years, roughly one in three traces back to missing or misapplied idempotency. Double charges, subscription double-starts, duplicate emails on checkout retries. All variants of the same bug: the client or a proxy retried a POST and the server processed it twice.

The rule. Every mutating payment request carries a UUID generated before the first call. The server checks its inbox. Hit → return the cached response. Miss → process and store. The key lives at least 24 hours (72 is better) to cover retries from timeouts, client restarts and CDN redeliveries.

Generate on the client, not the server. If the server generates the key, a network error between client and server produces a retry with a new key and a new charge. A client-generated UUID covers the full round trip.

Namespace the key. Reusing one key across authorize, capture and refund opens strange bugs. Prefix with the operation: uuid:authorize, uuid:capture, uuid:refund.

Carry it through to the provider. Stripe accepts Idempotency-Key on every mutating call and de-dupes for 24 hours (per its API docs); Adyen and Braintree do the same. Forward your key, don’t drop it at the adapter boundary.

Webhook reliability: signatures, replay, dedup

Verify signatures on every request. Stripe signs with HMAC-SHA256. Compute the expected signature against the raw request body — not the framework-parsed JSON, which may reorder keys, before you trust any field. A missing or wrong signature is a 401 without reading the body.

Reject old timestamps. Replay attacks resend old signed payloads. Include the timestamp in the signed header and reject anything more than five minutes old. Stripe’s Stripe-Signature already carries it; use it.

Dedupe by event id. Gateways retry at-least-once. Your handler must be idempotent by event.id. Store processed ids in an inbox table with 90-day retention and return 200 for repeats without running the handler twice.

Acknowledge fast, process async. Your webhook endpoint writes to a queue (SQS, Kafka, RabbitMQ, a database table) and returns 200 in under 200 ms. A separate worker does the real work. Processing can be slow without your acknowledgement being slow, retries stop, and webhook latency p95 stays green.

Handle out-of-order delivery. Events arrive in any order. A payment_intent.succeeded can land before payment_intent.created. Design handlers around the current state of the aggregate, not the sequence of events.

Payment gateway testing: sandbox to chaos

Payment gateway testing is the discipline that separates “it worked on my machine” from “it survived Black Friday.” It is a pipeline of six gates. Sandbox green is the first one, not the finish line. Here is the sequence every release passes before the launch email goes out.

Figure 3. The six-gate payment gateway testing pipeline — each gate catches a failure class the previous one structurally can’t, ending with a real-card charge on production.

1. Sandbox and test cards. Every gateway ships a sandbox with test card numbers for success, decline, 3DS challenge, insufficient funds, stolen card, expired card and wrong CVV. Enumerate a matrix of at least 30 scenarios per flow (checkout, subscription start, renewal, cancellation, refund, partial refund, chargeback). This is table stakes — and where most guides stop.

2. Functional and integration test cases. Drive the full return-URL flow for success, failure and customer cancellation. Assert that UI state, backend state, webhook state and the ledger all agree at the end of each scenario. A payment that shows “success” in the UI but never recorded a captured charge is the exact bug this gate exists to catch.

3. API and automation testing in CI. Wrap the scenario matrix in automated tests that hit the gateway sandbox and run on every pull request. Mock the gateway for unit-level speed; run a smaller live-sandbox suite in CI for contract confidence. If a card-network change breaks your integration, the pipeline should go red before your customers do.

4. Security and penetration testing. Payment pages are the most-attacked surface you own. Cover PCI DSS 4.0.1 Requirement 6.4.3 (authorize and integrity-check every script on the checkout page) and 11.6.1 (weekly tamper detection for skimmers). Add the scheme-mandated cadence: quarterly external vulnerability scans and an annual penetration test. Tools: Qualys, Rapid7, Source Defense, Feroot.

5. Production smoke test. Sandbox green does not mean production green — credentials, webhook endpoints, DNS, secrets and CSP all differ. Before launching a new method or flow, a QA engineer charges a real card on production, verifies UI plus backend plus webhook plus dashboard, then refunds immediately. It takes ten minutes and prevents the single most expensive class of bug there is.

6. Chaos and load. Inject gateway latency (500 ms, 2 s, 5 s), 5xx responses, webhook delays, reorders and DB write failures, and confirm the system degrades gracefully. Then simulate peak throughput — your Black-Friday peak is several times daily volume (plan for 3–5×), and a viral event 5–10× — for 30 minutes. Tools: toxiproxy, Chaos Mesh, Gremlin, k6, Locust. Every five minutes in production, a synthetic real-card transaction from three regions should complete a full checkout and refund, so alerts fire before customers report. See our broader testing playbook for how we structure this and how we report it.

Multi-provider failover and orchestration

Stripe publishes 99.99%+ uptime, but once a quarter there is a region-wide blip. A gateway latency spike can cascade into queued retries that drag a whole checkout down with it — the lesson is never “avoid Stripe,” it is “never be single-homed.”

DIY failover. Your adapter routes to a primary gateway; on a transient error (5xx, timeout) you retry against a secondary. Buildable in a week if you already have the adapter. The costs: two gateway accounts, two webhook endpoints, two sets of idempotency keys to reconcile.

Orchestration platforms. Spreedly, Gr4vy and Primer put a unified API in front of a large roster of gateways, a token vault, and rules-based routing (EU → Adyen, US → Stripe, fallback → PayPal). Failover latency under 100 ms. Typical cost 0.5–2% of revenue share plus per-transaction fees; a single hour of Black-Friday-class downtime pays it back.

PCI DSS 4.0.1: what matters in 2026

PCI DSS v4.0.1 is the standard in force, and all of its future-dated requirements became mandatory on 31 March 2025 (per the PCI Security Standards Council). The changes that actually alter engineering workloads:

Req 6.4.3 — payment-page script integrity. Every script that runs on a checkout page must be authorized, inventoried with a written justification, and integrity-checked (SHA-256 or Subresource Integrity). No unvetted third-party tags.

Req 11.6.1 — tamper detection. Automated change-and-tamper detection on payment pages and HTTP headers to catch skimmer injection. Tools: Source Defense, Feroot, or a purpose-built monitor.

MFA everywhere in the CDE. Every engineer, admin and script touching the cardholder data environment needs multi-factor auth. Hardware keys preferred.

Patch critical and high-severity vulnerabilities within one month. Requirement 6.3.3 keeps the one-month clock on the most serious CVEs; everything else on a risk-ranked schedule.

The shortcut. If you use Stripe Checkout, Braintree Hosted Fields or Adyen Drop-in, the card never touches your server. Your PCI scope shrinks from SAQ A-EP (an audit) to SAQ A (a self-assessed questionnaire), and the effort drops roughly 10-fold. Unless you have a specific reason to see PAN data, hand it to the gateway.

3DS and SCA without losing conversion

Strong Customer Authentication under PSD2 pushes a growing share of EU transactions through 3D Secure. Even with modern in-app 3DS 2.x, the industry sees roughly a 19% drop-off on the challenge step. Left untuned, 3DS is the biggest lever on your EU authorization rate — in both directions.

Exemption-first strategy. PSD2 exempts low-risk transactions (low-value, merchant-initiated, trusted beneficiary). ML-driven exemption selection lets you skip the challenge on 40–70% of traffic without raising fraud. Stripe Radar, Adyen RevenueProtect and Checkout.com all support this natively.

Frictionless flow. When the issuer grants the exemption, 3DS 2.x completes in the background with no user challenge. When it fails, present the challenge modal. Your SCA success rate is exemption_rate + (1 − exemption_rate) × challenge_pass_rate — optimize both terms.

Off-session recovery. Recurring payments can’t show a 3DS modal to a sleeping user. When an off-session auth fails with authentication_required, queue a follow-up: email the customer, have them authenticate on return, retry on-session.

Liability shift. 3DS-authenticated transactions shift chargeback liability to the issuer for fraud claims. If your chargeback rate is creeping up, turning 3DS on for a risky segment can lower it.

Fraud detection economics

Built-in (Stripe Radar, Adyen RevenueProtect). Included in most plans, ML-based, trained on network-scale data. Covers about 80% of the need for most SaaS and subscription products. Add custom rules for your business logic.

Third-party (Kount, Sift, Signifyd). Higher precision, richer signals (device fingerprinting, behavior, graph analysis), unified across multiple gateways. Cost $2–50K a month. Pick these when you run multi-gateway orchestration or your fraud rate is above industry average.

The false-decline math. A false decline costs roughly a third of that customer’s lifetime value; a fraud chargeback costs about $4.61 per $1 of fraud (LexisNexis True Cost of Fraud, 2025). Tune the threshold so false_decline_cost × false_decline_rate ≈ fraud_cost × fraud_rate. High-margin SaaS (over 40% gross margin) should accept more fraud to keep conversions; low-margin commerce (under 10%) should block harder.

Velocity checks that always pay off. Same card with five or more auths in ten minutes → block. Same card from three countries in an hour → challenge. A new card whose first three transactions pass → relax the rules.

Subscription lifecycle: dunning and retries

Involuntary churn, the failed recurring payments nobody recovered, runs at an average of 7.2% of subscribers a month, and subscription businesses are projected to lose around $129B to it in 2025 (Slicker, 2025). The median recovery rate hovers near 48%; a disciplined flow pushes that to 70–80%. Here is that flow.

Account updater. Visa Account Updater and Mastercard Automatic Billing Updater refresh reissued or expired card numbers automatically. Built in at Stripe, Adyen and Braintree. Recovers 10–15% of failures with no customer action. Turn it on before you write a line of dunning logic.

Retry schedule. Day 0 immediate retry (network token, account updater). Day 1 soft reminder. Day 3 firm warning. Day 4 pause access. Day 7, 14, 21, 30 retry with the updated card. Cohort-tuned schedules (ProsperStack, Churn Buster) optimize the days per segment.

Grace period. Keep access for 48–72 hours after the first failure. Users who fix their card within grace stay; users who lose access immediately churn.

Synchronize cancellations both ways. A cancel inside Stripe must reach your platform within seconds; a cancel from your UI must call the gateway. Drift here leaks revenue (customers kept after a gateway cancel) and triggers chargebacks (customers billed after a platform cancel).

Observability: RED dashboards and alerts

Rate. Authorizations, captures and refunds per second. Watch for unusual dips (outage, traffic regression) and spikes (retry storm, fraud ring).

Errors. Decline rate segmented by issuer country, card brand, BIN range and gateway region. A 3% uplift in one country is a different story than a 3% uplift globally.

Duration. Auth latency histograms (p50/p95/p99), webhook latency histograms, saga step durations. Feed the alert thresholds from the red/yellow/green table above.

Alerts worth paging on. Auth rate under 94% for 5 minutes, decline rate over 8% for 5 minutes, webhook latency p95 over 30 s for 5 minutes, retry queue depth over 10k for 5 minutes, chargeback rate over 1% on a 24-hour rolling window. Noise cap: no alert should fire more than once a week for a year unless something is genuinely wrong.

Tooling. Datadog, Grafana Cloud, New Relic, or self-hosted Prometheus and Grafana. Attach payment dashboards to the same stack your app uses so on-call finds them at 2 a.m., not behind a separate login. For the wider reliability picture, see how we build crash-proof software.

Gateways and orchestrators compared

Pricing below is standard published card-present-equivalent rates as of 2026; enterprise and interchange++ deals move these materially. Treat it as a starting map, not a quote.

Mini case: 91% to 97% authorization

Situation. A B2B SaaS client ran a Stripe-only integration with a flat 3DS-on-all-EU policy and no retry logic. Authorization sat at 91% globally, 82% in the EU, and involuntary churn was 9% of MRR. The CFO was weighing “migrate to a competitor gateway or cap EU marketing.”

12-week plan. Weeks 1–3 we refactored the direct Stripe calls behind a PaymentProvider adapter, added idempotency keys end to end and shipped webhook dedup. Weeks 4–6 we enabled Radar exemptions on low-risk EU traffic and built off-session authentication recovery. Weeks 7–9 we added Adyen behind the same adapter with automatic failover on 5xx. Weeks 10–12 we shipped a dunning flow with Visa Account Updater and a 72-hour grace period, and wired up seven RED-method dashboards.

Figure 4. The three numbers that moved over 12 weeks — roughly $900K of recovered annual revenue at the client’s $18M ARR, with chargebacks held flat.

Outcome. Global authorization climbed from 91% to 97.1% across the quarter. EU rose from 82% to 94%. Involuntary churn fell from 9% to 2.3%. Chargebacks held steady — the exemption engine did not import new fraud. The CFO shelved the “migrate or cap” conversation. Net effect at $18M ARR: about $900K of recovered annual revenue.

Want a similar numbers-grounded assessment on your stack? Book a 30-minute call and bring a weekly authorization-rate report.

A decision framework in five questions

1. What’s your GMV? Under $1M a year: Stripe Checkout and basic idempotency. $1M–$20M: adapter, outbox, dunning and synthetic monitoring. $20M+: orchestration, multi-gateway failover, a dedicated payments on-call.

2. Single region or multi-region? One region, one gateway is fine. Multi-region (especially EU + US) should always be dual-sourced — regional acquirers beat global ones by 3–5 points on local auth rate.

3. Is the product regulated? Healthcare (HIPAA), finance (SOC 2), EU personal data (GDPR), strict PCI: pick a gateway that signs BAAs and DPAs and let it see the card. Never process PAN yourself without a specific reason and an audit budget.

4. One-time or subscription? One-time: idempotency and webhook reliability are 80% of the job. Subscription: add dunning, account updater, synchronized cancellations and an off-session authentication flow.

5. Do you have a payments on-call? Yes: DIY orchestration is realistic and you’ll tune it. No: buy orchestration (Gr4vy, Primer, Spreedly). The worst answer is “no, but we built our own” — that’s how retry storms and data races reach production. If you don’t have the team, a dedicated development team that has shipped this before is cheaper than the first outage.

Five pitfalls that kill payment uptime

1. No idempotency. Or the key generated on the server instead of the client, or reused across authorize/capture/refund. All three variants ship double charges. Audit before you ship v1.

2. Synchronous webhook processing. The gateway times out your handler because it does three DB writes and a Slack post inline. Result: retries, duplicate events, state drift. Acknowledge in under 200 ms, process async.

3. Sandbox-only testing. Credentials, webhook URLs, fraud rules and 3DS flows differ between sandbox and production. Every release ships a production smoke test or you ship a launch-day outage.

4. Over-aggressive fraud rules. A 0.2% fraud rate at a 5% false-decline rate burns a third of lifetime value on those blocked buyers. Measure false declines explicitly; don’t assume aggressive is safer.

5. Single-gateway hard-coding. When Stripe has a regional blip, you take the blip with it. Ship the adapter even if you launch on one gateway — it turns adding a second into a week of work instead of a quarter.

KPIs to report to the business

Quality KPIs. Authorization rate (global plus top-5 regions), false-decline rate, chargeback rate (segmented by reason code), involuntary churn rate.

Business KPIs. Recovered revenue via dunning ($/month), blended processor cost as a percent of GMV, weighted average auth cost including failover, orchestration and fraud-tool fees.

Reliability KPIs. Auth latency p99, webhook latency p95, gateway availability per region, retry queue depth p95, saga completion rate.

When NOT to optimize payments

Pre-PMF products. Use Stripe Checkout, one gateway, one region, the minimum viable dunning. Spend the engineering hours on product-market fit; optimize later.

Under $1M GMV a year. Gateway fees of 2.9% are a line item, not a problem. Orchestration fees would outweigh the savings.

B2B enterprise on invoicing. If 90% of revenue is annual contracts paid by wire or ACH, fix your invoicing stack, not gateway tuning.

When the CEO has bigger problems. If retention is 70% and you’re optimizing false-decline rate, you’re mis-prioritizing. Fix the leaky bucket before optimizing the inflow.

FAQ

What is payment gateway testing?

Payment gateway testing verifies that a payment integration behaves correctly across success, failure and edge-case scenarios — in sandbox and in production. A complete pipeline runs six gates: sandbox test cards, functional and integration cases, automated API tests in CI, security and penetration testing, a real-card production smoke test, and chaos plus load testing. Sandbox green alone never means production green.

What is a good authorization rate for a SaaS product?

Card-not-present industry average is around 87%; B2B SaaS best-in-class sits at 96–98% (Gr4vy, 2026). Every point matters — on $10M GMV, 1% is $100K a year. Segment by issuer country and card brand; a global number hides the EU or Brazil story.

How do I prevent duplicate charges?

Use a client-generated idempotency key, forwarded through your adapter into the gateway’s Idempotency-Key header, with at least 24-hour (preferably 72-hour) server-side inbox retention. Namespace the key per operation: uuid:authorize, uuid:capture, uuid:refund.

What happens if my payment gateway goes down?

Without failover you stop taking money until the provider recovers. With DIY failover you retry against a secondary gateway on 5xx. With orchestration (Gr4vy, Primer, Spreedly) the swap happens automatically in under 100 ms. One hour of Black-Friday-class downtime typically pays for a year of orchestration fees.

Do I need PCI DSS compliance with Stripe Checkout?

Yes, but at SAQ A level — a short self-assessment questionnaire. Because the card never touches your infrastructure, scope is minimal. Collect card data on your own fields and you fall into SAQ A-EP and a much larger audit. Unless you have a specific reason, hand the card to the gateway.

How do I test payments in production without risk?

A QA engineer charges a real corporate card on production, validates UI, backend, webhook and dashboard within minutes, then refunds immediately. It takes about ten minutes per method per release and catches the class of bugs sandbox never sees — wrong live keys, webhook signature mismatch, a 3DS redirect blocked by production CSP.

How do I recover failed recurring payments?

Enable Visa Account Updater and Mastercard Automatic Billing Updater for automatic card refreshes (10–15% recovered). Add a dunning schedule: immediate retry on day 0, reminders and firm notices through day 3, pause on day 4, retries every 3–7 days to day 30. The industry median recovery is about 48%; a disciplined flow reaches 70–80%. Tools: ProsperStack, Churn Buster, or Stripe Billing APIs.

How much does it cost to build a resilient payment stack?

On an existing codebase with our agent-assisted engineering we typically scope a 3–6-week engagement for adapter, outbox, idempotency, webhook dedup, dunning and monitoring. A multi-provider orchestration layer adds 2–3 weeks. Exact scope depends on your volume and compliance surface.

What to read next

Ready to stop losing revenue to payment gremlins?

A reliable payment system is not one decision. It is a small set of disciplines kept in place: seven metrics on one dashboard, four architecture patterns in the code, a six-gate payment gateway testing pipeline on every release, and an incident playbook everyone on call knows. We apply the same rigor across our published engineering curriculum and every client build.

Teams that hold those disciplines hit 97%+ authorization, under 0.5% chargebacks, and recover 70–80% of involuntary subscription failures. Teams that don’t leave 1–3% of revenue on the table every month. The math favors the disciplined team every time.