EveryPay Eshop integration: Payform, plugins and payment verification

An EveryPay connector selects the appropriate payment flow and links verified results to store operations.

EveryPay's official instructions cover Payform, platforms including WooCommerce and Shopify, notifications and available payment methods. Direct API handling of card details has a specific PCI DSS SAQ D requirement and is not the default choice for every merchant. Select a route based on who handles sensitive data and which solution is enabled for the account. Establish sandbox access and verify configuration before production. Displaying a payment form correctly is only one stage; the order lifecycle and recovery behavior must also be tested.

Associate the order, amount and transaction, then consume the documented payment-result update. ERP posting and dispatch preparation should follow verified success rather than a browser message. Define what pending means for each method and how customers are informed. Where refunds are supported, keep the commercial request distinct from the financial movement. The relationship remains auditable when payment completion occurs later than initial order creation. Support staff should be able to inspect these stages without needing direct access to sensitive provider credentials.

Network interruption, repeated notifications or basket amount changes can produce a mismatch. Validate reference, amount and permitted state before applying an update. Keep private API credentials server-side and avoid recording card data in logs. If a provider shows success while the store remains pending, reconcile instead of requesting a second payment. Present failures clearly to customers while giving staff more diagnostic information without exposing access details. Retries should operate on the same transaction relationship rather than silently creating a replacement payment attempt.

Choose an EveryPay route because it suits the merchant, not because more custom code seems desirable. Document which party handles sensitive data and what can appear in diagnostic screens. Commercial actions use transaction references and verified states. Test each enabled method individually because a shared checkout appearance does not prove identical outcome behavior. For pending work, define a review time and owner. This makes connector maintenance understandable without depending on staff manually reading technical logs. Account-specific capability and the selected integration's responsibilities should remain explicit.

A shopper completes payment but loses connectivity before seeing confirmation. The store should update the order through the selected documented result route. Support compares reference and amount without requesting another payment. A repeated notification must not create another dispatch. If the basket changed before the final action, flag the mismatch. Test this scenario with the selected EveryPay solution and methods actually enabled for the account. The objective is an understandable order state even when the customer's browser never renders the expected final screen.

Acceptance covers successful and failed payment, duplicate updates and amount differences. Associate each result with the correct purchase and prevent another commercial action. Check test versus production configuration, refund permissions and safe secret handling. Logs must not contain card data or account keys. Staff approve what appears when a transaction needs reconciliation. Delivery includes recheck instructions rather than merely a screenshot of a successful form. Also confirm that support can distinguish an unpaid order from a paid transaction awaiting an internal update without exposing sensitive provider information.