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!
Stripe
Primer
Rapyd Cloud
Congrats on the launch day!
@alexcloudstar Thanks Alex!! Appreciate it
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.
@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.
@asadmalik901 Definitely. Because we are not tied to a bank or processor we are not beholden to anyone and in turn we are more than happy to assist with migrating your tokens in the even that you need them migrated. When a payment facilitator like a Stripe, Checkout.com or Airwallex or an MOR chooses not to migrate your tokens it's not always because they don't want to, it's usually because their underlying bank doesn't allow them to. Since we don't have / need an underlying bank we don't have the same restrictions making it our pleasure to migrate.
the VAMP dispute-ratio point caught my eye more than the vaulting story. you said running multiple processors lets you see the ratio per MID and rebalance before an account gets close to the line - but doesn't dynamic routing complicate the dispute side too? if a transaction gets routed to processor B today and the customer disputes it 60 days later, does that chargeback still land in processor B's dashboard for you to fight separately, or does PaymentKit pull disputes back into one place? feels like the reconciliation side of orchestration could be its own headache if it's not unified.
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?
@jean_mayer It's easier than most people expect, and no code needed. You map your customers, prices and subscriptions in the sandbox, validate on a subset, then cut over. Active subscriptions keep billing and nobody gets asked to re enter a card, since the tokens come with you. Setup is about an hour
I like this as revenue-side redundancy. AI founders obsess over multi-model routing for COGS; surprisingly few apply the same resilience logic to the revenue pipe.
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.
@thisiskp_ much appreciated!
Definitely shout out any pain points you're having on the payments side, since our dev team is cranking and always looking for ways to expand the platform!