Mark by AirtopMeet Mark. Vibe automation for marketers.
Promoted
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.
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.
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!!
Product Hunt Wrapped 2025
Congrats on the launch day!
PaymentKit
@alexcloudstar Thanks Alex!! Appreciate it
The soft decline cascading sounds useful. would love to see actual recovery numbers from your own portfolio.
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.
PaymentKit
@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.
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.