High-risk payment processing & getting a merchant account

If there's one step that makes or breaks a research-peptide business, it's payments. This is the item to start first and treat most seriously, because it takes the longest and because the wrong approach gets your funds frozen.

Why peptides are "high-risk"

Payment processors classify industries by risk. Research compounds land in the high-risk bucket because of factors like chargeback potential, regulatory scrutiny, and reputational sensitivity. "High-risk" doesn't mean illegitimate. It means processors apply stricter underwriting and pricing.

Why mainstream processors say no

Stripe, PayPal, Square, and Shopify Payments generally prohibit this category in their acceptable-use policies. Founders who slip through anyway often get a sudden account freeze and held funds once the processor's review catches up, sometimes weeks of revenue trapped. Do not build on a processor that prohibits your category. It's borrowed time.

What you actually need: a high-risk merchant account

A high-risk merchant account is issued by a processor/acquiring bank that knowingly serves your industry. You apply, go through underwriting, and once approved you become the merchant of record, with funds settling to your own business bank account. Expect:

• More documentation and a real underwriting review.
• Higher processing rates and possibly a rolling reserve.
• A requirement that your website and operations meet specific compliance standards (below).

What underwriters want to see

Approval, and staying approved, depends heavily on your website and operations. Underwriters typically look for:

• A registered entity, EIN, and matching business bank account.
• A live, professional website with clear product information.
• Research-use-only labeling and "not for human consumption" disclaimers.
• Clear Terms, Privacy, Refund/Return, and Shipping policies.
• Accurate pricing and no prohibited/medical claims.
• Age verification and restricted-jurisdiction controls where applicable.
• Working contact information and responsive customer support.
• Sometimes: COAs, supplier documentation, and projected volumes.

In other words, the compliance controls underwriters require aren't a side quest. They're the price of admission to accepting cards at all.

Always have backup rails

Even with an approved merchant account, smart operators keep manual payment options (ACH, wire, and where appropriate peer-to-peer methods) so a single processor hiccup never takes the business offline. Build your checkout to support more than one way to pay.

You are the merchant of record. Keep it that way

The healthiest model is bring-your-own: you own your merchant account and your funds settle directly to you. Avoid arrangements where a third party becomes merchant of record and holds your money. You give up control and margin. Your store software should plug your accounts in, not sit in the middle of your funds.

How pep.app fits

This is the problem the platform was built around, and it's worth being specific about how, because "we're compliance-focused" is a sentence any vendor can type. Three things do the work.

1. The guardrails live in the code, not in a policy document

Every control an underwriter looks for is enforced by the platform on every order, rather than left to your discipline: age verification, research-use-only framing on product, cart, and checkout, restricted-state blocking against the shipping address, per-lot COAs on product pages, real policy pages, and a timestamped audit trail behind all of it.

The distinction that matters is enforced versus configured. On a plugin-assembled store each of those is a separate component that can be switched off, left unlicensed, or silently broken by an update, and nobody finds out until a customer or a processor does. Here they're properties of the checkout itself. You can't accidentally sell into a blocked state, because the order won't go through.

2. Compliance re-checked every week, without you remembering

Approval isn't the finish line. Processors re-review live accounts, and the requirements move underneath you: a state changes its rules, a compound's status shifts, a page gets edited in a hurry and picks up language it shouldn't have.

So the storefront is checked automatically every week against the current rule set, and platform-level updates ship to every store rather than waiting for each operator to notice. If something on your store has drifted, it surfaces as a task to fix instead of as a finding in someone else's review. The practical effect: the store your processor approved is the store that's still running.

3. Rails that let you change processors without rebuilding

The most expensive assumption in this category is that your current processor is permanent. Payments are multi-rail from the start: your own merchant account as primary, a pre-arranged backup, and manual options (ACH, wire, and where appropriate peer-to-peer) behind those.

Switching is a configuration change, not a project. That matters because of what the alternative looks like. An account closes, an operator without a second rail spends the next weeks with checkout dark, applying under pressure, which is the exact sequence that lands sellers on the MATCH list. Redundancy arranged while everything is calm is the cheapest insurance in this business, and it only works if you arranged it in advance.

Underneath all three: you bring the accounts and you stay merchant of record. Funds settle to you, never through us. The platform's job is to make your store the kind of applicant underwriters approve, and to keep it that way after they do.

This guide is general information, not legal, financial, or payments advice. Processor policies, rates, and requirements vary and change over time. Always read your processor's acceptable-use policy and consult qualified professionals.