If you’ve built checkout software for a CBD store, a supplements subscription app, or a POS system for a firearms retailer, you’ve probably run into the problem that the integration works fine in every test you throw at it, but a few weeks after implementing it, the merchant account behind it gets shut down. You don’t find any error in the logs or anything wrong with the code, just an email saying the account’s been terminated.
It’s tempting to go back and comb through the integration looking for what broke. Nothing did. The card networks looked at the kind of businesses the software processed payments for, decided the risk wasn’t worth it, and pulled the plug. This is a common issue to run into when you’re building payment software for these high-risk verticals, and it’s much easier to design around if you know it’s coming before you build the checkout flow, not after.
The Code Your Software Never Sees
Every merchant account carries a Merchant Category Code, a label the card networks and banks use to sort businesses by industry. Your software never touches this directly, but instead lives at the account level, but it decides whether the software even gets to keep running. Some categories get sorted into the high-risk bucket, such as CBD, nutraceuticals, firearms and ammo, vape, credit repair, travel, and anything with recurring subscription billing. These industries generate more disputes and more compliance headaches than a typical retail or SaaS billing account, and every processor knows it.
Stripe, Square, and PayPal build their default underwriting around low-headache MCCs. So a piece of software that’s architecturally identical, whether it’s charging cards for a bookstore or a firearms accessories shop, can get treated completely differently depending on which merchant account sits behind the API call. Outside the safe zone, these platforms either decline the application before you write a line of code or approve it and shut it down later once dispute volume climbs. This has nothing to do with how well the software is built.
The Numbers Causing the Shutdowns
Once you see the actual thresholds the card networks enforce, it stops looking arbitrary and starts looking like straightforward risk math that any payment system has to be built around. Visa’s monitoring system (VAMP) reduces everything to a single ratio: fraud reports plus disputes, divided by settled transactions. In April of this year, the line for getting labeled “Excessive” dropped from 2.2% to 1.5% across North America, the EU, and Asia-Pacific. For subscription software processing 1,500 transactions a month, that’s about 22 disputes before enforcement kicks in, which is not a lot of room if the product has any real base of customers disputing charges instead of canceling through the app. Cross that line, and Visa can charge up to $8 per dispute, and acquiring banks would often rather shut the merchant account down rather than absorb their own penalty exposure.
Mastercard runs a similar system to Visa’s called their Excessive Chargeback Program. If a business has a hundred chargebacks in a month with a ratio above 1.5% then the account is flagged. If a business experiences three hundred chargebacks at a ratio of 3% then the fines may start running into six figures. Getting removed from either program requires three consecutive clean months; a single bad month resets the clock entirely, which matters a lot if your software’s billing cycle naturally produces disputes in bursts.
For any card-not-present software product (subscription platforms, e-commerce backends, POS systems serving these verticals) that hits these thresholds, it’s not an unlikely edge case worth a footnote in the risk assessment. It’s close to guaranteed, given enough months of normal usage. That’s the actual reason standard processors would rather not integrate with software built for these industries in the first place.
How Does this Affect how you Architect the Payment Layer
If you’re the one designing or specifying the payment stack for software in these verticals, there are a few things you need to make sure happen.
First, examine the underwriting relationship. The API integration was never the real problem. Wiring up a charge endpoint is a solved problem in almost any framework. What actually determines whether the software keeps working in six months is the underwriting relationship behind the endpoint that absorbs the risk when disputes spike. This is an infrastructure decision, not a coding decision, and it needs to happen before the checkout flow gets built, not after.
This is why many software teams evaluate specialists like PayKings during the architecture phase instead of after deployment. Working with a payment provider that understands high-risk merchant underwriting from the outset can help reduce the likelihood of disruptive processor changes, allowing engineering teams to build a payment stack around infrastructure designed for their industry’s risk profile.
Second, partner with high-risk payment processors. High-risk-focused processors are built specifically to solve this problem for software teams in these spaces. High-risk processors set reserves, fraud tooling, and underwriting terms based on the realities of the SaaS vertical rather than assuming every integration looks like a standard retail SaaS account. PayKings is built for this kind of integration work. For CBD, nutraceuticals, firearms, and similar high-risk categories that get turned away by standard gateway APIs PayKings’ high-risk merchant accounts are designed for the increased risk, resulting in a lower likelihood of shutdowns. Architecting a payment layer around a processor like that from day one tends to save a lot of rework compared to launching on Stripe and migrating mid-production once the account gets flagged.
Next, build dispute visibility into the software itself rather than treating it as an operations afterthought. Since chargeback thresholds run on ratios (not raw counts), wiring alert tools like Verifi or Ethoca into the payment flow, and getting the billing descriptor right in the checkout UI, buys real runway before an account gets anywhere near enforcement territory.
Last, but not least, don’t merely architect the payment layer around a single processor as a hard dependency. Given how quickly these programs escalate, software serving subscription or continuity billing in high-risk verticals should be built with a secondary processor as a failsafe. Relying on a single processor sets you up for a point of failure that could take the whole product down if one merchant account gets flagged.
Software Team Takeaways
Remember that Standard payment APIs aren’t rejecting software built for CBD, firearms, or nutraceutical businesses because of anything wrong with the code you’re producing. The APIs are rejecting it to avoid card network penalties. If you’re building payment infrastructure for one of these industries, design around the reality of chargebacks from the start. Pick an underwriting partner that actually works in the vertical that you’re building software for and be sure to build dispute visibility into the product early. Don’t assume a payment flow that passes every sandbox test will survive real customers as production scales.
Related Categories