Featured image of post ChatGPT Payment Links Explained: The 12-Step Stripe Protocol Behind Every Subscription
AI News

ChatGPT Payment Links Explained: The 12-Step Stripe Protocol Behind Every Subscription

From Checkout Session creation to webhook delivery — a technical breakdown of how Stripe processes a ChatGPT subscription payment, and why IP consistency, card BIN, and billing address each act as a gate for cross-region payments.

In AI account-trading circles, “pulling the link” is common slang: extracting the payment URL.

ChatGPT Plus checkout isn’t available in every region. If your IP or account region isn’t on the supported list, clicking “Upgrade” either hides the payment button or lands on a blank page. “Pulling the link” means getting the system to hand over the hidden Stripe Checkout URL — because without that URL, no payment can happen at all.

This article won’t teach you how to pull one. Instead, it answers a more useful question: what protocol actually runs behind that link, and how does Stripe decide whether to accept your money? Understanding the mechanics beats bookmarking a hundred “tutorials.”

The Big Picture: OpenAI Never Touches Your Card

Many people assume they pay OpenAI directly. In reality, OpenAI never sees your card number — it uses Stripe Checkout, a fully hosted payment page:

1

Your browser → OpenAI frontend → OpenAI backend → Stripe API → Stripe-hosted page → Issuing bank

The page where you type your card number lives on checkout.stripe.com. Card data goes straight into Stripe’s vault; OpenAI only receives a token meaning “paid.” This is the standard architecture for SaaS subscriptions — PCI DSS compliance is so expensive that no sane company touches raw card data.

The 12-Step Protocol

From clicking Upgrade to the Plus badge lighting up, a subscription actually walks through 12 steps:

Phase 1 — Session creation (steps 1-4)

  1. The browser requests the upgrade page; OpenAI’s backend validates account state (free tier? already subscribed?);
  2. The backend calls the Stripe API to create a Checkout Session, passing the price_id for Plus, success/cancel URLs, and customer info;
  3. Stripe returns a Session URL — this is the link that gets “pulled.” It lives for 24 hours and is not bound to the IP that generated it;
  4. The browser redirects to the hosted page at checkout.stripe.com.

Phase 2 — Payment submission (steps 5-8)

  1. You enter card details on the hosted page; Stripe.js tokenizes the card in-browser and sends it straight to Stripe, bypassing OpenAI’s servers entirely;
  2. Stripe creates a PaymentMethod object and kicks off risk evaluation (Radar scoring — details below);
  3. 3D Secure triggers if the issuing bank requires it: a bank page asks for an SMS code or password;
  4. The charge request routes through the card network (Visa/Mastercard) to the issuing bank.

Phase 3 — Fulfillment (steps 9-12)

  1. The issuer returns an authorization result: approved, insufficient funds, region mismatch, or a flat decline;
  2. Stripe writes the result back to the Checkout Session and fires a webhook to OpenAI’s callback endpoint;
  3. OpenAI verifies the webhook signature (to reject forged callbacks) and confirms payment_status = paid;
  4. The upgrade is written to the database, the success page renders, and Plus turns on.

The real cat-and-mouse game happens at steps 6 and 9.

The Three Gates of Cross-Region Payments

Why does the same card succeed for one person and fail for another? OpenAI’s and Stripe’s risk systems stack on top of each other, and they mainly look at three things:

Gate 1: IP consistency. The IP that created the Session, the IP that opened the payment page, and the account’s usual login IP — if those three span three different countries, the Radar score jumps. Note: the link itself doesn’t lock IPs; the scoring system does. That’s why “forwarding the link to a friend abroad to pay for you” works sometimes and fails other times.

Gate 2: Card BIN. The first 6-8 digits of a card number are the Bank Identification Number, which reveals the issuing bank and country. A US-BIN card paying from a US residential IP is low-risk; the same card paying from a datacenter IP is high-risk. Popular virtual-card BIN ranges have sat on risk lists for a long time — the more people abuse a BIN range, the more it’s flagged. That’s the real story behind “virtual card voodoo”: the card isn’t bad, the BIN range’s reputation is burned.

Gate 3: Billing address and local payment methods. Stripe runs AVS (Address Verification Service): if the ZIP code you enter doesn’t match what the bank has on file, the charge is declined. Stripe also supports region-specific local payment methods — a payment method issued in one region used from an IP in another is itself a risk signal.

The three gates multiply. Fail any one and the transaction dies; barely pass all three and the composite score can still cross the threshold.

Stripe Radar: The Invisible Referee

Radar is Stripe’s machine-learning risk engine, scoring every transaction from 0 to 99. The dimensions it inspects go far beyond what most users imagine:

  • Device fingerprint: browser environment, timezone, system language, font list;
  • Behavior: form-fill speed, mouse movement, whether the card number was typed or pasted;
  • Card profile: BIN risk tier, this card’s history across Stripe’s entire network;
  • IP profile: datacenter vs. residential, proxy-database hits, recent transaction volume from that IP;
  • Email profile: account age, disposable-email flags.

Scores above 75 are blocked by default; 65-75 forces 3DS verification. Most “mystery declines” — valid card, sufficient balance, still rejected — die at this layer. And the decline message is deliberately vague (“Your card was declined”), so you never learn which rule you hit.

The Defense Keeps Evolving

Since 2024, OpenAI has visibly tightened: detection of bulk-registration patterns, retroactive bans after successful payment (you paid, and days later the account is gone), and device-level correlation across multiple paying accounts. The battle has expanded from “the moment of payment” to “the entire account lifecycle.”

For developers building payment systems, there are three lessons worth stealing:

  1. Hosted checkout is the standard answer: never touch card data — push the compliance burden to your payment provider;
  2. Webhook signature verification is the floor: treat “paid” as true only when a server-verified webhook says so, never trust frontend redirects;
  3. Risk control is multiplicative: any single check (IP or BIN alone) can be gamed; only multi-signal combinations hold.

Compliance Note

This article is a technical analysis of payment protocols and risk-control mechanisms — not operational advice for cross-region subscriptions. Buying services across regions may violate platform terms, and account risk is your own. The right way to use this knowledge is to harden your own payment system.

Further reading: the “Payment / Security” section of this blog will keep publishing deep-dives on billing logic and risk-control mechanics.