iPhone in-depth Lesson 6: Merchant Variance [Springfield Scammin' Series]

[GarySpringfieldScammin’]

Lesson 6: Merchant Variance & Burp/Caido Tracing
Part 1 of 2 — continued in the first reply below.

Lesson 6: Merchant Variance and Burp/Caido Tracing​

Why the Same Card Works Here and Fails There​

Same card, same iPhone, same network. One store approves it. Another declines it. The merchant changed — and with it, the whole decision chain.

This lesson maps the three gates, the four sources of variance, the two fraud vendors most likely to decide behind the scenes, and how to watch a checkout with an intercepting proxy — Burp Suite or Caido — on your own devices only. Example: one online purchase of 91.92 dollars, paid with a typed card number.

The card is not approved or declined in the abstract. It is approved or declined by a specific merchant, through a specific processor, under a specific fraud policy.

Architecture: The Three Gates​

A payment passes through three gates. Failure at any one looks identical on screen: a decline, an error, or a silent failure.

Gate 1: The Merchant Fraud Gate​

Before the bank hears about the payment, the merchant — or its fraud vendor — scores it. Verified This gate runs first and can stop a payment before any authorization is sent.

Gate 2: The Issuer and Bank Gate​

If the merchant gate passes the order, authorization travels to the issuing bank, which checks balance, card status, address verification, CVV, and its own fraud models. Verified It can approve, decline, or demand 3-D Secure.

Gate 3: The Network and Processor Technical Gate​

This gate is plumbing, not judgement: routing, message acceptance, and the 3-D Secure flow must complete. A timeout, malformed field, or failed redirect can kill a payment both sides would have approved.

• Merchant gate: fraud vendor, rules, thresholds. Blocks before the bank.
• Issuer gate: bank authorization, balance, AVS, CVV, 3-D Secure.
• Technical gate: routing, network messaging, 3-D Secure handoff, timeouts, breakage.

Diagnostic question: did the bank even see it? No means the merchant gate stopped it. Yes and declined means the bank gate stopped it. Yes and approved but the order failed means the technical gate.

Trust Boundary: Who Decides, and On What Information​

Each gate trusts different information. The merchant trusts its fraud vendor and order history.

The bank trusts account data: balance, card status, recent transactions, and AVS and CVV results. It does not see mouse movements, the device fingerprint, or the browsing session.

The processor and network trust the message format only. No single party sees everything: the merchant sees behaviour but not the balance, the bank sees the account but not the behaviour, the network sees the message but not the buyer.

Weakness: Four Sources of Variance​

1. Fraud Vendors and Thresholds​

Merchants hire different vendors, or none, and configure them differently. Verified Vendor, configuration, and threshold are merchant choices, invisible to the buyer.

2. Rules: AVS, CVV, 3-D Secure, Velocity, Geography​

One merchant requires a full AVS match; another accepts a ZIP-only match. One triggers 3-D Secure on every first purchase; another never does. Velocity and geography rules differ.

3. Processor Plumbing​

Merchants use different processors, gateways, routing, and 3-D Secure providers. Inferred Plumbing explains a meaningful share of declines neither side can explain from its own logs, because each sees only half the chain.

4. Plain Breakage​

Sometimes nothing judged the payment: a script failed, a redirect looped, a cookie expired, or a gateway timed out. Breakage is unglamorous and common, and hard to diagnose without looking at the traffic.

Demonstration: The Variance Lab​

The Variance Lab is a teaching model, not real data. It holds the purchase constant — the same 91.92 dollar order, typed card, same iPhone — and varies only the merchant profile and signals.

Merchant profile	Fraud setup	Rules	Teaching-model outcome
A: large retailer, strict	Dedicated vendor, tight thresholds	Full AVS, 3-D Secure on first purchase	DECLINED, score 95
B: mid-size, balanced	Dedicated vendor, moderate thresholds	ZIP match accepted, 3-D Secure on high risk only	APPROVED after 3-D Secure
C: small shop, light controls	No vendor, gateway checks only	AVS and CVV only	APPROVED by the bank
D: digital goods, loose	Vendor in monitor mode	Mismatches flagged for review	APPROVED, flagged for review

Add four signals at once: typed card, first purchase, Private Relay masking the IP, and a ZIP that does not match the billing address. Each alone is weak. Stacked, they push Merchant A to a teaching-model score of 95, and the merchant gate declines before the bank is contacted.

Merchant B challenges rather than declines, so the purchase goes to 3-D Secure and approves. Merchant C never sees the stack, so the bank authorizes on AVS and CVV alone. Merchant D records the signals and approves anyway. Same card, same amount, same phone, four outcomes. Verified That is merchant variance: normal operation, not malfunction.

Evidence: Forter and Riskified​

Two fraud vendors appear repeatedly in checkout traces, and they work differently — which changes where the decision happens and who bears the cost when it is wrong.

Forter: Identity-Network Decisioning​

Forter runs from page load through checkout. Its JavaScript collects a device fingerprint, behavioural biometrics, network signals including true-IP and VPN or proxy detection, and transaction, account, and velocity signals. It sets cookies named forterToken and ftr_ncd. Verified Its API returns approve, decline, or not reviewed in under a second.

Forter typically decides before authorization, so a Forter decline means the bank may never see the attempt.

Riskified: Chargeback-Guarantee Decisioning​

Riskified works mainly after authorization. The merchant authorizes first, then submits the order to its decide endpoint: total, email, browser IP, addresses, card BIN with masked last four plus AVS and CVV results, line items, a device-fingerprint session token, and customer profile.

Riskified returns approved, declined, or under-review — a status, not a numeric score. Verified If Riskified approves an order that later chargebacks as fraud, it reimburses the merchant.

Neither vendor declines on a single rule. Declines come from stacked inconsistencies. One odd signal is usually survivable. Four at once usually is not.

Which vendor decides a given checkout is Unknown without a checkout-specific trace. Do not assume it from a homepage tracker list, and do not invent vendor weights, thresholds, or internals.

Evidence: Two Anonymized Merchant Examples​

Example One showed a bot-mitigation layer and a captcha labelled Additional security check during search, plus a captcha in the footer. Its privacy statement said it collects device identifier, IP address, key stroke patterns, cookies, and server logs for anti-fraud security measures. No dedicated fraud vendor or payment processor was named. Verified Absence of a visible vendor is not proof none is used.

Example Two showed a homepage tracker list of a consent-management geolocation service, an edge and bot-manager sensor, an analytics tag manager, and a real-user monitoring beacon. None is a dedicated fraud vendor. A site-wide diagram added two dedicated fraud vendors, thinly and likely checkout-only, plus a credit bureau, a buy-now-pay-later provider, and a payment wallet. Inferred The homepage understated the checkout reality. Inspect the checkout, not the homepage.

Continued in the first reply below — Part 2 of 2.

 

[GarySpringfieldScammin’]

Part 2 of 2 — continued from the thread above.

Demonstration: Burp Suite vs Caido​

An intercepting proxy sits between the iPhone or browser and the internet and logs every HTTP request and response: domains and their order — merchant, gateway, 3-D Secure, fraud vendor, analytics — plus headers, cookies, request bodies showing whether a token or raw card number was sent, and responses, status codes, and redirects. It also provides a Repeater for resending a modified request in authorized testing.

Capability	Burp Suite	Caido
Role	Intercepting proxy	Intercepting proxy
Maturity	Established, full-featured	Newer, lighter, open-source
Best fit	Deep testing, large engagements	Fast setup, focused tracing
Request log	Full HTTP history	Full HTTP history
Repeater	Yes, mature tooling	Yes
Learning curve	Steeper	Gentler

Choose Burp for the full toolkit, Caido for a lighter tool that gets you tracing quickly. For this lesson either is sufficient. Inferred The skill is reading the traffic, not the brand of the proxy.

Architecture: The 6-Step iPhone Proxy Setup​

For your own devices, accounts, and traffic only, or sites with explicit permission or a bug-bounty scope. Do not intercept other people traffic, or tamper with payment amounts.

1. Run the proxy on a computer on the same Wi-Fi as the iPhone.
2. Install the proxy CA certificate on the iPhone and trust it. Without this, HTTPS traffic cannot be decrypted.
3. Point the iPhone Wi-Fi proxy at the computer, using its local IP and port.
4. Turn Private Relay off, and any VPN off. Otherwise traffic bypasses the proxy.
5. Open the merchant site and browse to the payment screen. Confirm requests are logged.
6. Stop at the payment screen. Do not enter a real card unless it is a purchase you intend to make.

Burp Suite: Proxy tab, Options, Proxy Listeners, Running
Caido: Settings, check the listening address and port
iPhone: Settings, Wi-Fi, tap the network name,
Configure Proxy, Manual, Server, Port
Server: the computer local IP address
Port: the proxy listening port, commonly 8080
Turn off first: Private Relay, Off; and any VPN, Off

Demonstration: The 8-Request Traced Checkout​

Teaching model, not a real packet capture. Real checkouts vary by merchant, gateway, and vendor.

1. GET homepage and product page. Sets session cookies.
2. GET checkout page. Loads payment form and fraud-vendor JavaScript.
3. POST fraud-vendor session start. Sends fingerprint, receives a session identifier.
4. GET gateway tokenization script. Loads the card-field iframe.
5. POST gateway tokenize request. Sends card fields, receives a token. The raw card number never reaches the merchant.
6. POST submit order. Sends token, addresses, email, line items.
7. POST fraud-vendor decide request. Merchant forwards order details for a decision.
8. POST authorization request, then 3-D Secure redirect if challenged, then the response. First moment the bank is involved.

Requests 1 through 7 happen before the bank is contacted. If the vendor declines at request 7, request 8 never happens.

Trust Boundary: What a Proxy Cannot Show​

• Secure Element cryptograms. Wallet payments use a device account number and a one-time cryptogram made inside the Secure Element.
• Server-side scores. Score, weights, and threshold live on the vendor server.
• Certificate-pinned apps. Some native apps pin their certificate and refuse a proxy CA.
• Private Relay traffic. When Private Relay is on, traffic bypasses the local proxy.

A proxy shows what crossed the wire. It does not show what happened inside the server, inside the Secure Element, or inside a pinned app.

Experiment: The 7-Step Hands-On Tracing Protocol​

Trace your own checkout, on your own account and device, for a purchase you intend to make or a test order you abandon before payment.

1. Choose merchant and purchase. Note amount, card type, typed card or wallet.
2. Set up the proxy as above, Private Relay and VPN off.
3. Start the capture, browse, add the item to the cart.
4. Proceed to checkout and stop at the payment screen. Do not enter a real card unless you intend to complete the purchase.
5. Read the log in order. List every domain, labelled merchant, gateway, 3-D Secure, fraud vendor, analytics, or unknown.
6. Find the decision point: the decide request and response, and the authorization request. Record which happened and in what order.
7. Write down three answers: which domains saw the checkout, whether the bank was contacted, and what you still cannot see. Keep the log for your own records only.

Repeat the protocol at a second merchant and compare the domain lists. The differences are the variance, made visible.

Decision Lab: Did the Bank Even See It?​

Decide the most likely gate before opening each answer. Ask the bank: did you see an authorization attempt from this merchant? No attempt means the merchant gate blocked it; an attempt seen and declined means the bank gate declined it.

Scenario 1: First Purchase, Typed Card, Private Relay, ZIP Mismatch​

First order, typed card, Private Relay on, ZIP mismatch. Instant decline, no 3-D Secure, no bank notification.

Spoiler: Answer

Merchant fraud gate. Four stacked signals are the pattern a vendor declines before authorization. If the bank saw no attempt, the merchant gate stopped it.

Scenario 2: The Bank App Shows a Declined Attempt​

Checkout declines; minutes later your bank app shows a declined authorization attempt for the exact amount.

Spoiler: Answer

Bank gate. The authorization reached the issuer, which declined it. Ask the bank why: funds, fraud hold, AVS or CVV failure, or velocity.

Scenario 3: Approved by the Bank, Order Still Fails​

Bank app shows an approved authorization, possibly a pending hold, but the merchant site shows an order failure or no order appears.

Spoiler: Answer

Technical gate, or a post-authorization merchant decision. The bank approved, so the issuer gate passed. Suspects: failed 3-D Secure return, gateway timeout, post-authorization review, or order-system failure.

Scenario 4: Works in the App, Fails in Safari​

Same card and merchant succeed in the native app but decline in Safari with Private Relay on.

Spoiler: Answer

Merchant fraud gate treating the browser session differently, or Private Relay masking the IP. If the bank saw no Safari attempt, the difference is in the merchant gate, not the card.

Scenario 5: Works at Merchant C, Declines at Merchant A, Same Hour​

Same item at two merchants within the hour. Merchant C approves. Merchant A declines instantly, no bank notification.

Spoiler: Answer

Merchant variance, most likely the merchant fraud gate at Merchant A. Merchant C may have no vendor or a looser threshold. The card and bank are the same in both attempts.

Defense: What Merchants and Buyers Can Do​

For merchants, the defense is calibration, not maximum strictness. Challenge rather than decline on medium risk, use 3-D Secure as a step-up instead of a wall, and monitor declines where the bank never saw an attempt.

For buyers, the defense is understanding, not evasion. Keep billing details accurate. Use a wallet token where supported. Avoid stacking risk signals on a first purchase. If a payment declines, ask the bank the diagnostic question before retrying, because repeated retries are themselves a velocity signal.

Do not try to evade live fraud controls. Do not intercept traffic that is not yours, do not tamper with payment amounts, and do not use a proxy to manipulate a checkout. Verified Tracing here is for your own purchases and authorized testing only.

Discussion Prompts​

• In the Variance Lab, which single signal would you remove first, and why?
• A merchant says your order was declined for security but the bank saw no attempt. Who owns that decision?
• Forter decides before authorization; Riskified mainly after it. How does that change what asking the bank can reveal?
• Your proxy log shows an unexpected fraud-vendor domain. What do you ask next?
• When is a strict threshold good security, and when is it just turning away good customers?

Next Lesson​

Next lesson is Lesson 7: POS Terminals and Payment Protocols — the same 91.92 dollar purchase, made in a store instead of online, through a terminal, a chip, and a tap.