Eric Kuvykin

By Eric Kuvykin. Substantially revised October 17, 2026. The original publication date and URL are retained.

Start with the customer who changes channels

A customer may order online, collect at a store and later contact another location about a return. The difficult part is often the connection among those events. A business should evaluate omnichannel payments by whether the order, payment and service history remain understandable when the customer moves between channels.

Map a few common journeys before reviewing features. Include an item substitution, a partial pickup and a return to a different location where the business permits it. Record which system holds the authoritative order status and which provider controls the financial action.

Decide what can be shared and what must remain separate

A common customer view can help support, but staff do not all need the same access. Define who can see purchase history, issue a refund or change a delivery instruction. Preserve the legal entity and merchant account associated with each payment, especially when multiple locations use similar branding.

Ask the provider how permissions operate across stores and channels. A manager’s access to a local register should not be assumed to grant authority over every online account. Test the actual role settings and record the approval path for an exception.

Make the refund journey a buying test

Create a sample online order and attempt the supported in-store return process. Inspect the inventory change, customer receipt and accounting result. If a channel cannot issue the refund directly, document the handoff so staff can explain what will happen and who owns it.

Test partial refunds and mixed orders rather than only a full reversal. Determine how a promotion, delivery charge or multiple payment methods affects the record. These details should come from the platform’s supported behavior and the business’s reviewed policy, not a cashier improvising at the counter.

Close the loop in reporting

Reconcile channel totals to the payment reports and deposits. Keep an exception list for orders whose commercial status and payment status disagree. For example, a canceled pickup should not disappear from the order screen while leaving staff unaware of an unresolved payment.

The PCI Security Standards Council’s merchant resources are a useful starting point for checking how payment information moves across integrated systems. Review the responsibilities for the actual combination of website, software and terminal with the relevant providers. A unified interface does not by itself establish that sensitive data is handled appropriately.

For a New Jersey business selling online and at local events, include the temporary selling environment in the design. Confirm how mobile-device access is removed after the event and how returns find the original sale. This is a continuity and permissions example, not a claim that a particular local event requires a specific payment platform.

Write a short service script based on the tested process. It should explain what staff can do immediately, what needs approval and what the customer will receive as confirmation. Good omnichannel design gives customers continuity while leaving the business with a coherent financial trail.

Sources and next steps

Primary reference: PCI SSC’s merchant security resources. Use the current resource and confirm implementation details with the provider or appropriate adviser.

Related reading: Choosing a POS System: Test the Full Workday Before Signing; Digital Wallets: Test Acceptance, Refunds and Reporting Together.

For the wider operating context, continue to the New Jersey business operations guide on All State Merchants. Its state and local resources complement the payment workflow discussed here.

Eric Kuvykin writes about payments, fintech and business operations. Browse the article library for additional practical guides.