Last week PaymentKit finished #1 Product of the Day, #2 Product of the Week, and top 15 for the month. 457 upvotes and 106 comments.
The comments were the best part. A few were sharper than questions we get on sales calls, and two of them are now sitting in our internal notes.
Thank you to everyone who took the time!
Quick recap for anyone finding this now
PaymentKit.com didn t start as a random startup idea. Our parent company runs a portfolio of subscription brands, and for years we kept hitting the same three problems: billing lived in one tool, payments in another, revenue data in a third. Every processor change meant a migration. And all of it sat on top of a single processor whose risk team could change our business overnight.
We couldn t find anything that solved all three together, so we built Payment Kit and ran our own volume through it before selling it to anyone.
What it actually does:
Payment orchestration. Connect the processors you already use. Every transaction is routed to the one most likely to approve it, and soft declines cascade to the next one instead of turning into lost revenue.
Independent vaulting. Cards, Apple Pay and Google Pay are vaulted as network tokens under your control, not your processor s. Adding or dropping a processor is a routing change, not a migration, and your customers never enter a card again.
Billing and revenue data in the same place as payments. One system of record instead of three tools that disagree with each other.
The trial is free, so you can poke around without having to talk to a sales person.
If you d rather have someone look at your specific setup, we can set up a quick call. Not a sales thing. We spent a few years on the wrong side of these problems and most of what we learned is more useful in a conversation than on a landing page. Drop a comment here or find me on the product page.
Thanks again!
PaymentKit
Hey everyone, Diego here from the PaymentKit team.
Quick story on where this came from, because it explains most of the product.
PaymentKit didn't start as a startup idea. We built it for ourselves. Our parent company runs a portfolio of subscription brands, and for years we kept hitting the same three problems: billing lived in one tool, payments in another, and revenue data in a third. Every processor change meant a migration. Every decline was money we never saw again. And all of it sat on top of a single processor whose risk team could change our business overnight.
We couldn't find anything that solved all three together, so we built it and ran our own volume through it before selling it to anyone.
What it actually does:
Payment orchestration: Connect the processors you already use. Every transaction routes to the one most likely to approve it, and soft declines cascade to the next one automatically instead of turning into lost revenue.
Independent vaulting: The part we care most about. Cards, Apple Pay and Google Pay are all 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, and if a MID gets shut down your subscribers never feel it.
Subscription billing: Flat, tiered, usage based or hybrid pricing. Hosted checkout and self service portals, live without writing code.
Revenue metrics: One dashboard across every processor, so you can compare success rates and fees side by side instead of stitching exports together.
What that actually produces: More than 10% lift in authorization rates on average after merchants switch.
It comes from three things stacked: routing each transaction to the processor most likely to approve it, cascading soft declines instead of eating them, and network tokens that keep cards on file alive longer. One merchant went from 63% to 76%. There's also a risk side that most people only learn the hard way. 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, and 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. 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.
Why I think this community in particular might care: a lot of you are running SaaS or digital products on a single processor, or on a merchant of record that owns your customer data and your tokens. That works right up until it doesn't. We're the layer that makes that decision reversible.
It goes live in under an hour on top of what you already have, and there's a free trial if you want to poke at it.
Would really like to hear from anyone who's been through a processor shutdown, a rolling reserve, or a migration that broke their subscriptions. What did you wish existed at that moment?
@diego_vidal10 Upvoted PaymentKit. The independent vaulting is particularly compelling, especially for subscription businesses where processor changes can become painful migrations. The ability to keep customer payment credentials portable seems like a meaningful advantage.
@diego_vidal10 Congrats on the launch, and very cool product! The fact you built this for yourselves first says a lot.
Stripe is working on multi-processor routing, and it's in beta: https://docs.stripe.com/payments/orchestration/route-payments. I'm sure there are differences in the approach, can you explain those? When would it make sense to use Stripe multi-processor vs PaymentKit?
PaymentKit
Thanks @benbartling!! Good question. The main difference is where the vault sits.
With Stripe's orchestration, Stripe stays the system of record. You can route to other processors, but the tokens and the dependency stay with Stripe. With PaymentKit the vault is independent, so no processor is the center of the stack. That distinction matters the day a risk team makes a decision about your account.
The other difference is scope. We're not only routing. Billing, payments and revenue data live in the same place, which was the actual problem we had internally. We're built for the case where you don't want any single processor to be the foundation
PaymentKit
@hamza_afzal_butt Yes, automatic. Every transaction tries your default processor first, and if it comes back a soft decline or the gateway is down, it cascades to the next processor in your priority order until it clears. No manual step, and the customer only ever experiences one attempt
Been using Payment Kit for a few months and I gotta say aside from the simple and seamless integration the product has really delivered. Ive created a few routing rules to test and now am moving the majority/all of our payments through Payment Kit.
One major callout: If you run subscriptions, VAMP and GMAP should be on your radar.
It's Visa/MC's monitoring programs: your fraud and dispute counts get combined into one ratio, and crossing the threshold gets your processor fined for keeping you. That's why merchants get dropped "out of nowhere." Most founders hear about it for the first time in a warning email, or sometimes just get dropped with no notice.
PaymentKit attacks both sides of the ratio. Smart routing controls which processor each transaction lands on so no single account's ratio collapses, and can be adjusted in real time based on need. AI-driven dunning recovers failed payments without retry storms that inflate fraud signals. Built-in fraud controls stop disputes before they're born.
We built this running 20+ subscription brands of our own, several in high-risk categories. Ask me anything about VAMP or multi-processor setups.
1752vc Pitch Deck Analyzer
Your own subscription brands were running on this before anyone else could buy it. Congrats on the launch. That is a lot of trust to put in your own code.
PaymentKit
@ben_kahan Thanks Ben. Honestly it changes how you build. When it's your own revenue clearing through your own code, you stop shipping things you plan to "monitor closely" and you fix the complicated failure paths first
Congratulations on the launch!!
PaymentKit
@yogesh_joshi9 Thanks Yogesh!!