Taking an order by phone sounds simple until the representative must honor everything the business already knows about the customer: a saved card, an account-specific price, a tax exemption, an available shipping method, and the actual cost to deliver the order. A direct connection between a customer relationship management (CRM) system and a payment processor could collect money, but it would leave those commerce decisions outside the system that owns them.
For this engagement, approximately 16,000 saved payment relationships already existed. The order desk needed to make those relationships usable without moving card data into the CRM or asking returning customers to start over. At the same time, representatives needed to quote the right price, obtain tax and shipping calculations, and create an order that fulfillment could process.
Phillips Web Development Company designed a custom orchestration layer around the existing systems. The CRM remained the representative’s workspace; the commerce platform remained the authority for catalog, customer pricing, tax, shipping, orders, and fulfillment; and the payment processor remained the authority for saved payment methods and charges. The application connected these responsibilities into one workflow, with persistent transaction state, identity checks, audit references, and recovery paths for partial failures.
The central design choice was to preserve valuable existing state rather than reproduce a commerce engine inside the CRM.
The decision: why a direct CRM-to-payment flow was insufficient
A representative could, in principle, select a contact in the CRM, enter an amount, charge a card, and create an order record. That path is attractive because it reduces the number of systems in the initial implementation. It also requires someone to answer questions that a payment form cannot answer:
- Which saved payment methods belong to this customer, and how can the customer authorize their use?
- Which price applies to each item for this customer’s account?
- Which discounts may be combined, and what amount should actually be charged?
- Is the customer exempt from tax, and what tax treatment applies to this delivery address?
- Which shipping services are available for these items and this address, and what do they cost?
- Which completed order should the warehouse fulfill, and what should support see if payment or order creation fails?
The organization already had answers to these questions in its commerce and payment infrastructure. Recreating them in the CRM would introduce a second, competing set of pricing, tax, and shipping rules. Charging a manually entered total would make reconciliation harder and could leave the customer with a payment but no fulfillable order.
The order desk therefore does not calculate a final charge in isolation. It assembles the intended purchase, asks the commerce platform for the applicable order economics, and uses the resulting reviewed total in the payment flow. Customer-specific pricing is applied in the commerce draft, and the commerce platform remains responsible for its tax treatment and shipping options. The payment processor continues to hold the saved card relationship. The orchestration layer coordinates these decisions and records how they became a completed sale.
System responsibilities
| Component | Responsibility |
|---|---|
| CRM | Contact context and the representative’s order-entry workspace |
| Commerce platform | Catalog, customer pricing rules, discounts, addresses, tax treatment, shipping calculation, order lifecycle, and fulfillment handoff |
| Payment processor | Saved payment relationships, secure card collection, payment authorization or capture, and payment records |
| Orchestration application | Customer identity mapping, draft lifecycle, transaction state, cross-system references, audit information, and recovery |
This division matters because no single component can commit a payment and a commerce order as one database transaction. The application must recognize each boundary and handle the possibility that one system succeeds while another is unavailable.
The representative workflow
1. Resolve the customer. The representative opens a contact in the CRM. The application verifies the request’s origin, identifies the representative from trusted session information, and resolves the corresponding commerce customer and payment relationship. When a linkage is missing, a candidate customer can be reviewed and linked only after conflict checks; an email match alone is not treated as proof of identity.
2. Build the order. The representative selects items and quantities in the CRM workspace. The application retrieves current catalog information and applies the customer’s pricing rules to the commerce draft. Discounts are handled within the commerce order so the representative can review the price that will be recorded there.
3. Calculate delivery and tax. The representative confirms shipping and billing details. The application asks the commerce platform to calculate eligible shipping options, costs, and tax for the draft. The displayed total is refreshed when the cart, address, pricing context, or selected shipping option changes. The final payment amount must be checked against the current draft before a charge is attempted.
4. Choose the payment path. For an eligible returning customer, the representative can use an existing saved payment relationship after obtaining appropriate authorization. A new card is collected through a secure payment component rather than through the CRM’s own fields. Eligible accounts can follow an invoice or purchase-order path instead of an immediate card charge. Those paths have different payment states and must be reported accordingly.
5. Complete and reconcile. The application coordinates the charge and order completion, then records references in the systems that need them. A representative sees a confirmation only when the resulting state is known. If the processor accepted a payment but the commerce platform did not complete the order, the case enters an exception path for reconciliation rather than being treated as an ordinary success or silently retried as a new sale.
Engineering the boundaries
One transaction reference across systems
Each order attempt receives a stable, non-customer-specific transaction reference. The application associates that reference with its own state and, where appropriate, the payment and commerce records. Support and finance can use the reference to trace a sale across systems without relying on a customer’s name, an amount, or a timestamp as the sole join key.
The reference is a correlation aid, not proof that the order is complete. The application checks actual payment and order states before reporting success or taking recovery action.
Drafts must follow the cart
Representatives need to go back, adjust quantities, change an address, and resume after an interruption. The application tracks an in-progress commerce draft and compares the purchase’s material inputs with the version last calculated. An unchanged cart can reuse its draft; a changed cart requires a refreshed draft and totals. Charging from an earlier screen’s displayed amount would be unsafe.
This lifecycle also prevents a routine screen revisit from producing a trail of unrelated drafts. The representative works with a single intended purchase while the application manages updates and recovery state behind it.
Payment retries require explicit state management
Idempotency helps prevent duplicate payment requests when a network call is repeated, but it does not eliminate the need to inspect the existing transaction. If a representative changes the card or the total after an attempt, the application must determine whether to continue, retrieve, or create a distinct payment attempt. Reusing an old request key with changed payment parameters can fail or produce an incorrect assumption about what was charged.
The design treats payment attempts as stateful operations: it checks the prior processor result and the current commerce total before another attempt. It avoids promising that a single idempotency key alone makes the entire cross-system workflow atomic.
A charged card is not a completed order
Payment capture and commerce order completion happen in separate systems. If a charge succeeds and order completion fails, blindly issuing another charge could double-bill the customer. Declaring success would be equally misleading.
The recovery path looks up the payment, draft, and resulting order by their recorded references, determines what completed, and surfaces exceptions for an operator to resolve and audit. A repair may complete the existing order, or it may require a different operational decision, including a refund. The key is to recover from observed state rather than replay the entire workflow without inspection.
Identity and audit must come from trusted sources
The representative’s identity comes from a verified CRM request, not a value submitted in an editable cart field. The application distinguishes who started a draft, who resumed it, and who initiated the payment. This helps support teams answer operational questions without conflating the latest person to touch an order with the person who charged it.
Customer linkage also crosses a trust boundary. A candidate match is reviewed, checked for conflicting associations, and recorded with an audit trail before it is used. Customer-facing notes and other editable fields are unsuitable as authoritative sources for payment identity or transaction ownership.
Security and payment handling
The order desk is designed to keep raw card details out of its application and CRM storage. Saved methods remain with the payment processor; new-card entry uses a processor-controlled collection flow. Representatives still need a clear authorization process for using a card on file, and any phone-based card capture has operational obligations beyond software design, including the handling of call recordings and staff procedures.
The payment path and its classification should be validated against the processor’s actual capabilities and the organization’s compliance requirements. A technical workflow alone does not establish PCI compliance or guarantee that a transaction has been classified as mail or telephone order.
What the architecture achieved
The order desk gives representatives one place to initiate a sale while continuing to use the systems that already own the customer’s payment relationship and the order’s economics. It avoids copying saved cards into a new application, avoids maintaining a parallel tax or shipping engine in the CRM, and gives operations a way to trace partial failures across system boundaries.
Its broader lesson is applicable to any organization modernizing an established sales process: a new interface should not force the business to abandon the state and rules that make its existing systems valuable. The engineering work is in assigning authority clearly, coordinating the handoffs, and making failure visible and recoverable.