Framer AI AgentsDesign and publish professional sites with AI
Launching today
PaymentKit
Billing that survives a processor shutdown
874 followers
Billing that survives a processor shutdown
874 followers
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
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.
Independent vaulting is the claim I'd want spelled out. Network tokens are provisioned against a token requestor, so whether they're portable depends entirely on who the requestor of record is, and Apple Pay and Google Pay DPANs make that messier rather than cleaner. If it's you and not the processor, put that sentence on the page, it's the difference between a real escape hatch and a vault you still can't leave with. Worth naming which processors you've actually moved live volume between too, not which ones you support.
PaymentKit
@asadmalik901 PaymentKit is the token requestor of record, not any individual processor. We hold our own Token Requestor ID (TRID) through VGS's direct integration with the card networks, so tokens are provisioned against us, not against a Stripe-specific or Adyen-specific requestor. VGS is the infrastructure we use to manage that relationship, but the TRID, and the tokens tied to it, are ours. That's what makes them portable: no processor in the chain provisioned the token or can lock it to themselves. On live volume: we've moved production transactions across Stripe, Authorize.net, Adyen, Airwallex, NMI, etc using the same vaulted tokens, not just configured support for each.
On Apple Pay / Google Pay specifically: we don't request a device token (DPAN) if we can help it. At checkout, we request a merchant token (MPAN), which is tied to our merchant account rather than the customer's phone. The first charge uses a short-lived cryptogram alongside the token, standard for wallet transactions, and the network returns a network_transaction_id. From that point on, we hold the network token plus that network_transaction_id as the sole permanent record; nothing is left stored at whichever processor handled the first charge. Renewals reference that network_transaction_id directly, no cryptogram required, and can be sent to a different processor than the one that ran the original charge. We also register our own endpoint for card-update notifications, so when a customer's bank reissues a card, we get notified directly, confirm the details with Apple/Google, and update our own record. The processor never sees or stores the update; we just supply the current expiry at renewal time.
The DPAN fallback only kicks in if the card's issuing bank doesn't support merchant tokens.
@shawnsheikh That's a better answer than I expected, and the MPAN choice is the part I hadn't thought about. The follow up though is that owning the TRID moves the lock-in to you instead of to Stripe, which is fine right up until it isn't. What does the exit look like if PaymentKit shuts down or gets acquired, can I take the vault with me? That's the line I'd want on the page more than the processor list.
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.
PaymentKit
@chandrshekhar_rawen We usually recommend you have a few back up processors already set up in Payment Kit. When you have this set up we can do a few things:
Switching from one processor to the other takes 5 seconds, literally swap which primary processor you want to do use in our settings
If you have multiple processors integrated we can do cascading and retries on multiple processors both on first purchase and on rebills. So if a transaction doesn't work on one processor, we'll try it on another one in your account. We've found that this increases authorization rates by 5 - 10%
This is true risk mitigation and only works because we actually do full network token vaulting.
Interesting idea, but curious how refunds, disputes, and reporting work when everything is spread across multiple processors.
PaymentKit
@evan_taft1 Refunds run from PaymentKit, full or prorated, and the subscription stays in sync.
Reporting consolidates into one dashboard, so you compare processors side by side on success rate and cost instead of exporting from each one and reconciling by hand.
Disputes are the honest exception. They're resolved by the acquirer that processed that specific transaction, that's how the card networks work, and no orchestration layer changes it. What we do is upstream, with fraud rules that block the transactions most likely to become disputes: country, card brand, card type, amount or BIN, etc. Thanks for taking the time to comment Evan!
@diego_vidal10 Got it, thanks for clarifying. The reporting side makes a lot of sense, especially having everything in one place instead of pulling data from different processors.
The token ownership piece is probably the most interesting part here. Being able to switch processors without impacting existing subscriptions solves a pretty painful problem for subscription businesses.
I've dealt with payment migrations before. getting customers to update cards is painful, so this solves a real headache.
PaymentKit
@grant_w1 Exactly it. Card re collection is where most migrations quietly die. With network tokens under your control the customer never sees a new form
@diego_vidal10 Exactly. The customer side is usually the hardest part of any payment migration. Making the switch without disrupting active subscriptions solves a problem many teams only notice when they’re already dealing with it.
This could be useful for SaaS companies handling subscriptions across different regions.
PaymentKit
@daniel_carter19 That's one of the clearer use cases. You can route by geography, so EU payments go to one processor and US to another, same integration and same subscription logic (since local acquiring usually approves more)
@diego_vidal10 That makes sense. Being able to route payments by region without changing the whole setup is a pretty useful advantage for SaaS teams expanding globally. Thanks for explaining!
How much control do we get over feedback attempts?
PaymentKit
@jonathan_hayes3 Unlimited control. You can use our smart dunning where our system takes into account time of day, card type, processor, etc and does the retry when the system thinks it's most likely to go through. There's proprietary AI used there. If you want to use a manual, custom schedule you can do that as well.