The required phone reaches the order but not the handoff

Confirm that the value belongs to this order

Choose an existing affected order and its matching fulfillment or CRM record. Keep their references and event times inside the authorized systems. Confirm that the phone is stored on the order itself, rather than merely displayed from a customer profile or visible in a current checkout field. Note whether it was present when the handoff ran or added afterward; today's order view alone does not prove what an earlier export received.

Record the field's technical identifier and how it was added. A label reading Phone is not enough to distinguish a standard contact field from an additional field created by an extension. Ask the maintainer to identify the saved location if the administration screen shows a label without a field key. Do not guess a storage key from the label or replace the value with a different contact's number.

Keep collection behavior separate from handoff behavior

WooCommerce's Stripe express-checkout documentation says supported additional fields on the checkout page can be collected and saved to the order. The documented product and cart express paths do not display those additional fields and can send them empty. The behavior depends on how the field was registered and where the buyer started checkout.

That distinction is useful when comparing affected orders, but this investigation starts with confirmed storage. Once the relevant order contains the phone, the next question is whether the actual integration reads that location. The express-checkout document does not establish that a CRM connector, warehouse export or separate API consumer automatically includes the field.

If you discover the field was never stored, return to the collection and checkout-path investigation. Do not call that a downstream mapping omission. Preserve the required-field control while investigating; removing validation would not repair a missing destination mapping.

Locate the first missing or changed handoff

Use the integration's existing configuration and available records to compare the saved field with what the connector read. Then inspect the mapping and any available outgoing record. Record the exact source and destination field names, whether the value is present, and whether a transformation was applied. Keep the phone number itself in the restricted order system; the worksheet only needs the finding.

If the field is available to the connector but has no mapping, the omission is a mapping question. If it is missing from what the connector reads, investigate that earlier read or export boundary. If the outgoing record contains it but the destination does not, inspect the destination's import result and field association. A documented validation rejection and a value saved to the wrong destination field need different corrections. An unavailable log leaves a gap, not proof of either cause.

For a REST API integration, WooCommerce documents keys linked to a WordPress user with Read, Write or Read/Write permissions. Establish which authorized integration and permission scope are involved without copying the key or secret. Those access settings do not themselves show which custom fields the connector maps. Giving broader write access is not evidence that a missing phone mapping has been repaired.

Agree on the destination and the evidence of repair

Confirm which recipient needs the phone and for what operational purpose before arranging its transfer. A fulfillment contact field and a CRM contact field need their own named destinations. Successful collection does not answer whether both recipients are authorized to receive it, or which person's number each expects.

Assign the correction to the owner of the first established gap. Agree on the field pair, any documented format requirement, and how the destination will show that the transfer succeeded. For existing orders, decide separately whether a targeted update is needed. Do not resend an entire order merely to move one value until the integration owner has checked whether that action could repeat fulfillment or customer communications.

A Prism checkout-review consultation can start with the platform, field identifier and the point where the trace stops. Describe the requested investigation so scope, responsibilities, fees and terms can be confirmed before work. Send no phone numbers, order exports or credentials through the public form. Follow-up is by email; a request does not buy an integration change.

Phone handoff trace

Follow one real affected order through the systems you are authorized to inspect. Record field identifiers, timestamps and present/absent findings without copying the phone or customer identity. The earliest demonstrated gap determines the next owner; an unobserved stage remains unknown.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.