Merchant account underwriting exists to answer one question: how likely is this business to generate chargebacks, fraud losses, or card-network fines that land on the processor? The website is the first evidence a reviewer has, because it is the same thing a cardholder sees before deciding to dispute a charge.

A customer who cannot find a refund policy calls their bank instead of the merchant. A customer who cannot find a phone number does the same. Every gap on the site that pushes a confused buyer toward a chargeback is a gap the underwriter is paid to notice. So the review typically starts where the cardholder starts: on the public pages, reading them the way an annoyed customer would.

This is worth internalizing because it changes how you prepare. The site does not need to impress the reviewer. It needs to convince them that a cardholder can understand what they bought, what it costs, how to get help, and how to get their money back.

Four policy pages come up in nearly every underwriting review, and each one maps to a specific risk the processor carries.

A refund policy page is usually the first stop. Card-network rules require the return policy to be disclosed to the cardholder before purchase, and reviewers look for a policy that is findable from the footer, specific about timelines and conditions, and consistent with what the checkout says. A vague line like “contact us about returns” reads as a chargeback generator. A policy that states the window, the condition requirements, and who pays return shipping reads as a merchant who resolves disputes directly.

Contact information comes next. Reviewers typically want a real way to reach the business: a monitored email address at minimum, and often a phone number and a physical address. A site whose only contact path is a form with no stated response time suggests that unhappy customers will route their complaints through their card issuer.

Ecommerce terms and conditions define the sale itself: what is being sold, when it ships, what happens on cancellation, and which state’s law governs. Underwriters read these for consistency with the application. If the terms describe a subscription and the application says one-time sales, that mismatch becomes a question, and questions slow approvals.

A privacy policy rounds out the set. Processors expect one because card data and customer data flow through the site, and because several states now require privacy disclosures for commercial websites. The policy needs to reflect what the site actually does: which data is collected, whether it is shared, and how a customer asks for deletion.

None of these pages requires a lawyer to draft a first version, though regulated categories often justify one. What they require is specificity and agreement with the rest of the site.

Policy pages get applications delayed. Product descriptions get them declined.

Reviewers read product copy for two things. The first is clarity: can a cardholder tell exactly what they are buying, at what price, in what quantity? Ambiguous bundles, prices that only appear at checkout, and descriptions that oversell what ships in the box all predict disputes.

The second is claims, and this is where regulated categories live or die. A supplement page that promises to cure a condition, a wellness product described with medical language, a legal-adjacent product framed in terms that suggest an illegal use: each of these can move a business from “approvable with conditions” to “prohibited” in a reviewer’s coding of the account. Card networks publish rules about deceptive marketing, and processors are fined when their merchants break them, so underwriters read product pages with those rules in mind.

The pattern that survives review is copy that describes the product, its ingredients or specifications, and its intended use in factual terms, with required disclaimers where a category calls for them. Owners often resist this because factual copy feels less persuasive. In a watched category, the persuasive version can cost you the account that makes selling possible at all.

Beyond the copy, reviewers check a short list of technical signals.

SSL is the baseline: the site loads over HTTPS everywhere, not just at checkout, with a valid certificate. A mixed-content warning on a payment page is the kind of detail that gets screenshotted into an underwriting file.

The checkout needs to exist and function at review time. Underwriters commonly walk a purchase to the final step to confirm the flow, the stated currency, and the point where terms are disclosed. A site that is half-built, hidden behind a password, or running a “coming soon” page cannot be underwritten, because there is nothing to evaluate. Applying before the site is live is one of the most common self-inflicted delays.

The name question matters more than most owners expect. The legal entity on the application, the brand on the website, and the billing descriptor that will appear on cardholder statements should connect visibly. When “Sunrise Botanicals LLC” applies for an account, the site says “Herbal Haven,” and the proposed descriptor says something else again, a cardholder who checks their statement will not recognize the charge. Unrecognized charges become disputes, and reviewers know it. Putting the legal name in the site footer and matching the descriptor to the customer-facing brand closes most of this gap.

A theme runs through all of this: underwriters are pattern-matching for consistency. The application says average ticket is $40; the site’s cheapest product is $200. The application claims US-only sales; the site quotes international shipping. The application describes cosmetics; the blog describes therapeutic effects.

Any one mismatch may have an innocent explanation. But a reviewer processing a queue of applications does not investigate innocence. Mismatches read as either sloppiness or concealment, and both raise the perceived risk of the file. The practical consequence is that the site and the application need to be reconciled against each other before submission, line by line, by someone reading both documents in one sitting.

The sequence that catches problems efficiently runs like this:

1. Confirm the site is live, fully public, and serves every page over valid HTTPS.
2. Read the refund policy, terms, privacy policy, and contact page as a stranger, and fix gaps in specificity.
3. Reread every product description for pricing clarity and for claims a card network could call deceptive.
4. Walk the checkout to the final step and note where terms and the refund policy are disclosed.
5. Reconcile the legal name, the site brand, the descriptor, and every figure on the application against the site.

Most merchant sites fail somewhere in steps two and three, and most of those failures are a few hours of writing to correct. That is a far better trade than resubmitting a declined application to a second processor, which typically asks why the first one said no.

Boston Web Group runs this exact audit on merchant sites before they apply, and fixing what it finds is usually the fastest part of the whole underwriting process. Ask for one before you submit.