Tutorials··8 min read

How to Place an Order on Behalf of a Customer in WooCommerce

B2B sales reps take phone orders all day. A customer calls, describes what they want, the rep places the order, the customer pays later via invoice (or confirms a saved card). This is a core B2B workflow that retail-first WooCommerce stores ignore — which is why retrofitting it to an existing store is often painful.

There are three patterns. Each has tradeoffs. Picking the right one depends on how your reps work and how your pricing is structured.

The three patterns

Pattern A: Admin creates order from the backend

WooCommerce has a built-in Add New Order screen under WooCommerce → Orders → Add Order. You pick a customer, add line items, enter quantities, save.

When it works: simple orders, customers with straightforward pricing, no role-specific rules to worry about.

Problems:

  • The admin order screen doesn't apply most of your front-end pricing logic. Role-based prices, tiered discounts, coupons, shipping zone logic — all of these run at checkout on the storefront, not in admin. An admin-created order uses the raw product price, not the customer's wholesale rate.
  • Shipping methods shown in admin are the global set, not the customer's role-specific set.
  • Payment methods are the global set.
  • Tax applies based on the default calculation, not the customer's is_vat_exempt flag (though some tax plugins do respect this).

If your store has any dynamic pricing, admin-created orders will be wrong half the time.

Pattern B: Impersonate the customer and check out as them

Admin logs in as the customer (using a proper login as customer tool), navigates the storefront normally, adds items to cart, completes checkout.

When it works: always. This is the most reliable pattern because it reuses all your normal storefront logic.

Downsides:

  • Admin has to actually browse the store — slower than bulk-adding line items from admin
  • You need a proper impersonation tool with audit logging
  • Customer's cart (if they had one) gets overwritten; save-and-restore logic matters

This is our recommended pattern for most B2B stores.

Pattern C: Dedicated "assisted ordering" interface

Some plugins add a new admin screen that combines the best of A and B: the admin stays in the backend, but the order calculation uses the storefront logic (respecting role, tax, shipping rules). They simulate the customer session internally.

When it works: when the plugin implementing this is solid. Look for ones that explicitly apply the customer's role-based pricing and checkout context.

Downsides:

  • Feature quality varies a lot between plugins
  • Can get confused by complex multi-plugin pricing stacks

Pattern B in detail (the recommended one)

Since this is what we recommend, here's the full flow:

  1. Admin navigates to the customer's profile in WP admin
  2. Clicks "Shop As Customer" (or equivalent in your impersonation plugin)
  3. Is now logged in as the customer, with a persistent bar showing the impersonation
  4. Browses the store — sees role-specific pricing, hidden products, role-gated shipping/payment options
  5. Adds items to cart — this cart belongs to the customer; if the customer had items, decide if you replace or merge
  6. Goes to checkout — customer's saved addresses pre-fill; customer's role-specific rules apply
  7. Selects payment method — for account customers, "Invoice on Account" might be the only option, which is fine
  8. Places order — order is tied to the customer's account; rep's identity is logged as the placer
  9. Reverts to admin — one click; back to the rep's own session

The order looks like a normal customer order except for the admin-placed tag in its metadata.

Keeping the customer's state intact

When you impersonate, a few things about the customer's account need to be preserved:

Their cart

If the customer had a cart before you impersonated, you'll see it. Decide:

  • Replace it with what you're ordering. Safer if the customer didn't know they had a cart.
  • Merge with your line items. Riskier — the customer ends up paying for things they added and you may not know about.
  • Snapshot and restore: save their cart state before impersonation, place the admin order, restore. This is what our Shop As Customer does by default.

Their saved addresses

Shouldn't be touched. The customer's billing/shipping addresses pre-fill for your order; don't overwrite them unless explicitly entering a one-off address for this order.

Their payment methods

If the customer has a saved card (via WooCommerce Stripe, WooPayments, etc.), the admin can usually select it at checkout. This is how "confirm the saved card" phone-order flows work.

Caveat: some payment gateways require the customer to be physically present (3DS / SCA for EU). If you can't pass 3DS as an admin, the order will bounce. Plan for this — use "Invoice on Account" as the payment method for phone orders, and take payment separately after.

Their recently-viewed / wishlist

These are tied to the user session. Imposter browsing adds to their activity. Usually harmless — but if your store has a "suggest based on browsing" feature, it'll get skewed by your activity. Live with it or turn it off during impersonation.

Tax and tax-exempt status

If the customer is tax-exempt (using our Tax Exempt plugin or similar), their exemption should automatically apply when you check out as them. Verify this on your first test order — if the order email shows tax when it shouldn't, something's wrong with your impersonation flow (you might be using Pattern A accidentally).

Audit trail for assisted orders

Every admin-placed order should have metadata identifying:

  • Who placed it (admin user ID)
  • When the impersonation started (timestamp)
  • IP address of the admin
  • Reason (optional but recommended: "Phone order per customer request, 10:42am EST")

Without this, an order placed during impersonation looks identical to an order the customer placed themselves. Which is fine until the customer says "I didn't place that" — then you need the metadata to answer.

A decent impersonation plugin tags orders automatically. If you're rolling your own:

add_action( 'woocommerce_checkout_order_processed', function ( $order_id ) {
    $impersonator_id = get_impersonator_id_from_session(); // your helper
    if ( $impersonator_id ) {
        update_post_meta( $order_id, '_placed_by_admin', $impersonator_id );
        update_post_meta( $order_id, '_placed_as_customer', 'yes' );
    }
});

Show this metadata on the admin order view:

add_action( 'woocommerce_admin_order_data_after_order_details', function ( $order ) {
    $admin_id = $order->get_meta( '_placed_by_admin' );
    if ( $admin_id ) {
        $admin = get_userdata( $admin_id );
        echo '<p><strong>Order placed by admin:</strong> ' . esc_html( $admin->display_name ) . '</p>';
    }
});

Edge cases

Customer account not yet approved

If your store has moderated registration (pending/approved states), can you impersonate a pending customer? Usually you shouldn't — the customer hasn't agreed to terms yet. Some impersonation plugins gate this; check yours.

Multi-admin stores

If two reps work the same customer account simultaneously, impersonation can collide. Rep A impersonates, adds items, gets distracted. Rep B impersonates, overwrites the cart. This is rare but it happens. Mitigation: time-limit impersonation sessions, or reject new impersonation attempts if one is already active for the same customer.

Payment gateway 3DS

As mentioned above — some gateways require customer-present authentication. If 3DS fails during impersonation, the order bounces. Use "Invoice on Account" or a non-3DS gateway for phone orders.

GDPR / privacy

EU customers may have rights around who accessed their account. A proper audit log is also your compliance answer: you can prove admin X logged in at 10:42, did nothing but place one order, and logged out at 10:48. Without that log, answering a GDPR request becomes harder.

When the admin order screen is enough

If your store is simple — flat pricing, no role rules, no tax exemptions — Pattern A (admin-created order from Add New Order) is fine. It's fast. It doesn't need plugins.

The minute you have role-based pricing, role-based shipping, or tax exemptions, Pattern B becomes the right call.

The short version

  • Three patterns: admin-creates-order, impersonate-and-checkout, dedicated-assisted-ordering-plugin
  • Impersonate-and-checkout is the safest and most accurate for complex B2B stores
  • Keep customer state (cart, addresses, payment methods) intact
  • Tag every admin-placed order with the admin's identity
  • Handle 3DS/SCA by using account-pay gateways, not customer-card gateways