The Processor Isn’t Your Business — But It Can End It
Every cross-border operator I know has the same nightmare tucked away in a drawer. You build a subscription brand, a DTC box, a SaaS tool with recurring revenue. You pick a processor — Stripe because it’s easy, Adyen because you’re scaling internationally, Airwallex because you need multi-currency without the headache. And then one day, without warning, your MID gets frozen. Your rolling reserve kicks in. Your chargeback ratio ticks over some invisible line. And suddenly the thing you built — the brand, the retention curve, the LTV math you’ve been pitching to investors — is hostage to a risk team you’ve never met, at a bank you don’t have a relationship with, making decisions that can zero out your cash flow in a week.
That’s not a niche problem. That’s the structural vulnerability of running a recurring revenue business on someone else’s rails. The product I’m looking at this week — PaymentKit — is built to be the escape hatch from that trap. And for cross-border sellers specifically, the timing couldn’t be more relevant. Because the platforms we sell on are consolidating their payment stacks, the processors we rely on are tightening their risk models, and the cost of being locked into a single acquirer is going up just as the margin for error is going down.
The Three-Body Problem of Subscription Payments
Here’s what PaymentKit’s founder Diego Vidal describes as the origin story, and it’s one that will sound familiar to anyone who’s run a portfolio of brands: billing lived in one tool, payments in another, revenue data in a third. Every processor change meant a migration. Every decline was money never seen again. And all of it sat on top of a single processor whose risk team could change the business overnight.
That’s the three-body problem of modern subscription commerce. You’ve got your billing engine — say Chargebee or Recurly — handling plans, proration, dunning. You’ve got your processor — Stripe, Adyen, Authorize.net — actually moving money. And you’ve got your analytics layer — Baremetrics or a custom dashboard — telling you what’s happening after the fact. None of them talk to each other natively. None of them give you a unified view of what’s actually being approved, declined, or lost. And none of them protect you from the single point of failure that sits underneath all three.
PaymentKit’s pitch is that it sits on top of all of it — a payment orchestration layer that connects the processors you already use, routes each transaction to the one most likely to approve it, and holds the vaulted card credentials independent of any single processor. The billing logic, the hosted checkout, the revenue dashboard — those are features. The vault is the product.
Why Amazon sellers should care more than Shopify ones
If you’re selling on Shopify, you’ve got a bit more room to maneuver. Shopify Payments is convenient, but you can also bolt on third-party gateways, and the platform doesn’t force you into a single acquiring relationship. You can route around problems.
Amazon is different. If you’re an Amazon Seller Central operator running Subscribe & Save or any recurring model, you’re playing inside a walled garden where Amazon controls the payment rails, the buyer data, and the token vault. You don’t get to choose your processor. You don’t get to see your decline rates at the MID level. You don’t get to rebalance volume across acquirers when one of them starts flagging you. The lesson of PaymentKit — that token portability and processor independence are existential issues, not optimization opportunities — is one Amazon sellers should internalize even though they can’t act on it directly. Because the moment Amazon decides to change its risk parameters, or a new Temu or SHEIN marketplace emerges with better economics, you want to know exactly what your exit path looks like before you need it.
What PaymentKit Actually Does — And Why the Vault Is the Whole Game
Let me break down the four pieces, because the marketing copy buries the lede.
Payment orchestration. This is the least interesting part, frankly. Routing transactions to the processor most likely to approve them is a well-established pattern — Spreedly and Braintree have been doing variations of this for years. The soft-decline cascading — where a transaction that gets a “try again later” from one processor automatically flows to the next — is genuinely useful, and the claim of a more than 10% lift in authorization rates after merchants switch is the kind of number that gets a CFO’s attention. One merchant going from 63% to 76% authorization is the difference between a healthy subscription business and one that’s slowly bleeding out.
Independent vaulting. This is the part that matters, and it’s where the founders are making a claim that’s either revolutionary or marketing spin. The pitch: cards, Apple Pay, and Google Pay are vaulted as network tokens under your control, not your processor’s. You can add or drop a processor without asking a single customer to re-enter anything. If a MID gets shut down, your subscribers never feel it.
The skeptical read, which a commenter named Asad M. raises in the thread, is that network tokens are provisioned against a token requestor, and whether they’re portable depends entirely on who the requestor of record is. If PaymentKit is the token requestor, you’ve just swapped Stripe lock-in for PaymentKit lock-in. That’s a fair concern.
The founder’s response is detailed enough to be credible. PaymentKit holds its own Token Requestor ID (TRID) through VGS’s direct integration with the card networks. Tokens are provisioned against PaymentKit, not against a Stripe-specific or Adyen-specific requestor. They’ve moved production transactions across Stripe, Authorize.net, Adyen, Airwallex, and NMI using the same vaulted tokens. And for wallet payments, they deliberately request a merchant token (MPAN) rather than a device token (DPAN) — so the token is tied to their merchant account, not the customer’s phone, and renewals reference a network_transaction_id that can be sent to a different processor than the one that ran the original charge.
That last bit is the detail that separates this from vaporware. Most orchestration layers talk about portability in theory. PaymentKit is describing a specific technical mechanism — the MPAN versus DPAN distinction, the network_transaction_id as the permanent record, the direct registration for card-update notifications — that suggests they’ve actually done the work.
Subscription billing. Flat, tiered, usage-based, hybrid. Hosted checkout and self-service portals. This is table stakes in 2025 — Chargebee, Paddle, and Recurly all do this. The differentiator isn’t the billing logic; it’s that the billing logic is natively integrated with the orchestration and vaulting layers. You’re not stitching together a billing tool and a payment tool and hoping the webhooks line up.
Revenue metrics. One dashboard across every processor, comparing success rates and fees side by side. Again, not novel on its own — Baremetrics and ChartMogul do this for the analytics side. But having it native to the orchestration layer, so you can see which processor is actually performing better in real time and shift volume accordingly, is genuinely useful.
Where the Math Breaks — And Where It Doesn’t
The VAMP detail is the one that should make every cross-border operator sit up. Visa dropped the excessive VAMP threshold from 2.20% to 1.50% on April 1st this year across the US, Canada, Europe, and Asia Pacific. The ratio is measured per MID, not per company. If all your volume sits in one account, one bad month becomes a company-level problem.
Let me translate that for the non-payments folks in the room. VAMP is Visa’s fraud monitoring program. If your fraud-to-volume ratio exceeds a certain threshold, you get slapped with fines and fees that can eat your entire margin. The threshold just got 32% stricter. And it’s measured per merchant ID — meaning if you run five brands through one processor account, you’re pooling your risk. One bad product launch, one bot attack on your checkout page, one promo code that gets scraped by fraudsters, and your entire portfolio gets penalized.
The PaymentKit argument is that running multiple processors means you see the ratio per MID instead of hearing about it from your acquirer after the fact, and you can rebalance volume before any single account gets near the line. That’s not a feature — that’s risk management that can save your business.
The honest counterpoint, which the founders acknowledge in the thread, is disputes are still resolved by the acquirer that processed the transaction. No orchestration layer changes how card networks work. What PaymentKit does is upstream — fraud rules that block transactions most likely to become disputes, by country, card brand, card type, amount, or BIN. That’s useful, but it’s not a silver bullet. You’re still at the mercy of the acquirer’s dispute process when something goes wrong.
Where the math breaks
The pricing isn’t disclosed on the Product Hunt page, which is a yellow flag for a tool that’s asking you to move your entire payment stack onto it. The free trial is mentioned, but the actual cost structure — setup fees, per-transaction fees, monthly minimums — is absent. For a cross-border operator running thin margins, that’s a material omission. Payment orchestration tools typically charge a basis point or two on top of your processor fees, and that can add up fast when you’re moving six or seven figures a month.
The other place the math gets tricky is the migration claim. The founders say they’re happy to assist with migrating tokens if you ever need to leave PaymentKit. That’s the right thing to say, but the reality is that token migration between vaults is technically complex, and the incentives of the party holding the vault are rarely aligned with making the exit seamless. Asad’s follow-up question in the thread — what does the exit look like if PaymentKit shuts down or gets acquired — is the right question, and the founder’s answer (“we are more than happy to assist”) is the kind of answer you give before you have a term sheet on the table.
What Cross-Border Sellers Can Actually Borrow From This
Here’s the thing — most of you reading this aren’t going to switch to PaymentKit this week. The integration cost, the unfamiliarity, the risk of moving your payment stack mid-growth — it’s a lot to take on. But the principles behind it are things you can apply immediately, regardless of what platform or processor you’re on.
First, audit your processor concentration risk. If all your volume runs through a single MID, you’re one risk decision away from a cash flow crisis. The VAMP threshold change isn’t hypothetical — it’s already in effect. Pull your fraud-to-volume ratio, understand where you stand relative to the 1.50% line, and think about what you’d do if your processor froze your account tomorrow. Do you have a backup acquirer already onboarded? Can you route around a shutdown? If the answer is no, that’s a project, not a someday.
Second, understand who owns your tokens. If you’re on Stripe, Stripe owns the vault. If you’re on Adyen, Adyen owns the vault. If you’re on a merchant of record like Paddle, they own the vault and the customer relationship. That’s not necessarily bad — it’s just important to know what you’re giving up. The moment you want to switch processors, or negotiate better rates, or respond to a risk event, your leverage is directly proportional to your ability to walk away. Token portability is leverage.
Third, think about geographic routing. The PaymentKit founders mention that you can route by geography — EU payments to one processor, US to another — since local acquiring usually approves more. That’s a real pattern for cross-border operators. If you’re selling into Europe from a US-based entity, your authorization rates on EU cards are likely lower than they’d be with a local acquirer. The same logic applies to Shopify Markets sellers expanding internationally. Local acquiring isn’t just a cost optimization — it’s a revenue optimization.
Fourth, pay attention to the dunning intelligence. The founders mention smart dunning that takes into account time of day, card type, processor, and other factors to determine when retries are most likely to succeed. That’s the kind of incremental optimization that adds a percentage point or two to your recovery rate — which, on a subscription book, compounds meaningfully over time. Whether you’re on Klaviyo for email or Chargebee for billing, look at how your dunning is configured. Are you retrying at the same time every day? Are you treating all card types the same? The data exists to do better.
My Judgment — Where It Falls Short
Let me be direct about the limitations, because a product that solves real problems still deserves a skeptical eye.
The lock-in question is unresolved. PaymentKit’s answer to “what if you get acquired or shut down” is “we’ll help you migrate.” That’s the right answer, but it’s also the answer every company gives before they’re acquired by a Stripe or a Checkout.com or an Airwallex. The reality is that token vaults are valuable assets, and the company holding them has every incentive to make migration difficult. I’d want contractual language around token portability — not a promise, but a legal commitment with technical specifications — before I moved my entire subscription book onto their rails.
The processor list is thin. The founders mention Stripe, Authorize.net, Adyen, Airwallex, and NMI as processors they’ve moved live volume between. That’s a solid set, but it’s missing some of the names cross-border operators actually use — PayPal for marketplaces, Payoneer for cross-border payouts, Worldpay for enterprise volume. The claim is that the architecture is processor-agnostic, but “we support” and “we’ve moved live volume” are different things, and the latter list is what matters.
The dispute reality is understated. The founders are honest that disputes are resolved by the acquirer, and that’s correct. But the implication that fraud rules can meaningfully reduce dispute rates is optimistic. A lot of chargebacks come from customer confusion, not fraud — subscription renewals that people didn’t recognize on their statements, free trials that auto-converted, and so on. Those aren’t going to be caught by a BIN-based fraud rule. They’re going to be caught by better checkout UX and clearer billing descriptors, which are outside PaymentKit’s scope.
The pricing opacity is a problem. Not disclosing pricing on a Product Hunt launch is a choice. For a product that’s asking you to move your payment stack — your revenue infrastructure — onto it, the absence of a public pricing page makes it harder to evaluate the ROI math. The 10% authorization lift is compelling, but I need to know what that lift costs me before I can decide if it’s worth it.
What I’d Watch / Test Next
Here’s what I’d actually do this week, as an operator, based on this launch.
Run a processor concentration audit. List every account where you process payments. For each one, ask: what’s my monthly volume, what’s my fraud ratio, what’s my reserve situation, and what happens if this account gets frozen tomorrow? If you don’t have a backup processor already integrated, start the onboarding process now. The time to set up a relationship is before you need it, not after.
Test PaymentKit’s free trial on a small, non-critical subscription product. Don’t migrate your main book. Take a side project, a low-volume SKU, a test brand — and run it through their orchestration layer for a month. Measure the authorization rate before and after. See if the vaulting actually works the way it’s described. Ask the hard questions about token portability and get the answers in writing.
Pressure-test the VAMP exposure. If you’re running a single MID and you’re anywhere near the 1.50% threshold, that’s an emergency, not a project. Talk to your acquirer about your current ratio. If they won’t tell you, that’s a red flag. Consider splitting volume across multiple MIDs — even if it’s with the same processor — to isolate risk.
Look at your dunning configuration. Whether you use PaymentKit or not, the smart dunning concept is worth stealing. Review your retry schedules. Are you retrying at times when customers are most likely to have funds available? Are you treating different card types differently? The data exists to optimize this, and it’s a low-effort, high-impact change.
The bottom line: PaymentKit is solving a real problem — the structural vulnerability of running recurring revenue on a single processor’s rails. The vaulting architecture is genuinely interesting, and the VAMP threshold change makes the risk case more urgent than ever. But the lock-in question is unresolved, the pricing is opaque, and the dispute reality is more complex than the marketing suggests. Test it on a small product. Ask the hard questions. And regardless of whether you adopt it, take the principles — processor independence, token portability, geographic routing, smart dunning — and apply them to whatever stack you’re on today. Your future self, dealing with a frozen MID and a portfolio at risk, will thank you.
