Phone and Email Orders Without the Card Risk: Hosted Payment Pages for WooCommerce

August 6, 2026 at 09:30 AM

The order that doesn't come through checkout

Not every sale starts on your storefront. A regular customer calls in with a reorder. A B2B account emails a purchase list they've sent you for three years. Someone asks for a price you only give to people who've bought from you before. None of that fits neatly into a "browse, add to cart, checkout" flow, but it still needs to become a real order with a real payment behind it.

The instinct in a lot of shops is to just take the card number over the phone and key it into a terminal or payment form. It works, but it comes with a cost that's easy to underestimate.

Why keying in a card number is the expensive shortcut

Taking a card number by phone puts you squarely into MOTO territory, Mail Order/Telephone Order, which card networks and PCI DSS treat as higher risk than a normal card-present sale, because there's no chip, no PIN, and usually no 3-D Secure step to fall back on. In the UK alone, providers estimate that around half a billion MOTO payments are processed every year, and the compliance burden that comes with them hasn't gotten lighter, PCI Telecom's breakdown of MOTO scope is a good primer on what's actually required if you keep this in-house.

Two things make this expensive in practice:

• Compliance scope. The moment a staff member can hear or type a full card number, that person, their device, and often your whole call environment falls inside PCI DSS scope, frequently the difference between a lightweight self-assessment questionnaire and a much heavier one.
• Liability. Because MOTO transactions are card-not-present and regulators have exempted phone payments from Strong Customer Authentication, chargeback risk sits with the merchant, not the card issuer. A disputed phone order is much harder to win than a disputed in-person one.

None of this means you should stop taking phone and email orders. It means the card number shouldn't be the thing that travels between the customer and your staff.

Build the order first, let the customer pay themselves

The pattern that solves this is simple: create the order in your store admin exactly as it should look, customer, line items, shipping, any special pricing, and then hand the customer a secure, hosted link to complete payment themselves. Nobody on your side ever sees or handles the card data, and the order still lands in your system through the same rails as any other sale.

This is exactly the gap the Hosted Payment Pages feature in the Briqpay for WooCommerce plugin is built to close, and it's worth walking through because the mechanics generalize well beyond Briqpay specifically.

In practice, the workflow looks like this:

1. You add a new order in WooCommerce → Orders → Add order, set the customer, and add the line items, including any negotiated pricing.
2. Once the order is saved, a Briqpay Hosted Payment Page box appears in the order screen. You pick a flow and generate a link.
3. You send that link to the customer by email, SMS, or read it out over the phone as a URL, no digits change hands.
4. The customer opens the link, pays, and the order flows through the same webhook-driven process as a normal storefront order: it moves to processing, and captures or refunds happen from the existing payment details box on the order.

Nothing about the order's downstream lifecycle changes. Captures, refunds, and status transitions all use the same admin tools you'd use for a checkout-originated order, the hosted page is just a different front door onto the same house.

There's a nice safeguard built in, too: if the total on the hosted page ever drifts from the WooCommerce order total, page creation fails rather than silently letting a mismatched payment go through, which matters more than it sounds, since a mismatch that slips through tends to surface as a stalled or disputed order later.

Why this shows up so often in B2B

If this sounds like a niche workflow, it's worth noting how common the underlying situation actually is in B2B commerce. Despite years of investment in self-service portals, a lot of B2B buyers still end up back on the phone or in their inbox, often precisely because the self-service option feels like a checkbox rather than something built for how they actually buy. Sana Commerce's 2026 B2B trends report points out that impractical portals push buyers straight back to the channels they know work: a phone call or an email to someone they already have a relationship with.

That relationship is usually the whole point. B2B accounts frequently have negotiated pricing, credit terms, or minimum order quantities that don't map onto a public price list, and the person who understands that arrangement is the account manager on the phone, not necessarily the storefront. Being able to build that order exactly as agreed, in the admin panel, and then hand the customer a payment step that fits their business (rather than a consumer checkout) is what makes this workflow useful well beyond one-off consumer phone orders.

Where payment aggregation earns its keep

There's a second reason hosted payment pages are worth setting up properly, and it has less to do with security and more to do with what the customer is actually offered once they land on the page.

A hosted payment page is only as useful as the payment methods behind it. If it only supports one card scheme or one BNPL provider, you've solved the security problem but reintroduced a conversion problem, and it's a bigger one than people expect. Industry analysis on checkout friction has found that missing a customer's preferred payment method contributes to roughly 40% of checkout abandonment, which is a meaningful number for a link you're sending to someone who already intends to pay.

This is where payment aggregation matters. Rather than integrating each payment method one at a time, a card acquirer here, an invoice provider there, a BNPL scheme somewhere else, an aggregated setup gives a hosted page access to a broader spread of methods through a single connection, including ones that often don't have simple out-of-the-box support, like B2B invoice and installment options or region-specific credit products. For a merchant taking a special-terms B2B order, that can be the difference between offering the payment terms the customer actually asked for and offering the one method you happened to have plugged in.

The advantage compounds when the aggregation sits inside your e-commerce platform rather than bolted on separately: the same rails that handle a storefront checkout, order syncing, capture and refund tooling, webhook-driven status updates, also handle the hosted-page order, so a phone or email sale doesn't become a manual reconciliation exercise once the payment clears.

The takeaway

Phone and email orders aren't going away, particularly in B2B, and there's no good reason to solve them by putting card numbers in front of staff who shouldn't have to handle them. Building the order in admin and letting the customer complete payment on a hosted page keeps the compliance burden where it belongs, keeps the order on the same rails as everything else in your store, and with the right payment methods behind it, gives the customer a way to pay that actually matches how they buy.