PaymentKit is a multi-processor billing platform for SaaS and e-commerce. It routes payments across processors, vaults tokens independently, and keeps subscriptions billing even if a MID gets shut down. No code to launch, full API when you need it.
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?
Really like the idea of treating payment processors as replaceable infrastructure instead of something your entire billing stack depends on. Curious how hard it is to migrate an existing saas with active subscriptions into this app?
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.
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.
Congrats on shipping! Processor shutdowns are a total nightmare for SaaS businesses, so having built-in failovers for billing infrastructure is a huge stress reliever. Smart problem to tackle head-on.
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.
Payment reliability does not get enough attention until billing suddenly stops working. Building resilience into the payment layer from the beginning seems like a much better approach than reacting after a shutdown.
Been burned by a processor freeze before so this hits close to home. Curious how long it actually takes to add a new processor once you're set up.
Really interesting approach to making billing more resilient. Processor dependency is a bigger risk than many teams realize.
A strong solution for companies managing recurring payments. Reducing single points of failure can make a big difference.
I really love this idea because a processor going down can cause a lot of issue. keeping subscriptions running in the background could save businnesses a lot of stress.
Smart approach to reducing processor dependency. This could save teams a lot of headaches.
I like that this came out of a real internal problem instead of a market gap search. That usually means the edge cases are already handled.
Multi processor routing makes a lot sense for recurring businesses. Nice launch.
Love the resilience angle here. Keeping subscriptions running during disruptions is huge.
This feels especially useful for SaaS comapanies that cannot afford billing interruptions. Great concept.
@diego_vidal10 This is a genuinely practical problem to solve. The independent token vault+ multi processor routing is especially interesting processor shutdowns can become a huge operational headache for SaaS businesses. Nice launch.
This feels less like a payment feature and more like business continuity infrastructure especially for subscription heavy SaaS.
About PaymentKit on Product Hunt
“Billing that survives a processor shutdown”
PaymentKit launched on Product Hunt on August 24th, 2026 and earned 391 upvotes and 83 comments, earning #1 Product of the Day. PaymentKit is a multi-processor billing platform for SaaS and e-commerce. It routes payments across processors, vaults tokens independently, and keeps subscriptions billing even if a MID gets shut down. No code to launch, full API when you need it.
PaymentKit was featured in Fintech (47.4k followers), SaaS (43.8k followers) and E-Commerce (41.8k followers) on Product Hunt. Together, these topics include over 91k products, making this a competitive space to launch in.
Who hunted PaymentKit?
PaymentKit was hunted by Ben Lang. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how PaymentKit stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
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?