Nexi XPay Eshop integration: selecting a flow and checking transactions

A Nexi XPay connection starts with the merchant's actual product and a controlled order-to-payment workflow.

The official XPay Greece developer portal distinguishes Hosted Payment Page, Pay-by-Link, Server to Server and In-App SDK. These routes are not equivalent and should not be assumed active under every agreement. Confirm the merchant product and commerce platform before proposing implementation. Architecture should minimize unnecessary exposure to payment data and explain what access is required for testing and production. Specific capabilities need verification in the current documentation for the selected route rather than importing assumptions from another Nexi product or market.

Connect the internal order reference, final amount and corresponding transaction. Browser return does not replace the payment-result check required by the chosen solution. A payment link may instead relate to an order created by support and needs clear validity and status rules. Document each scenario separately so a payment outside checkout does not become an untraceable financial record. Warehouse and accounting teams need a stable relationship to the real purchase, while customer support should understand whether a transaction concerns a confirmed order or an outstanding offer.

Repeated clicks, checkout abandonment and delayed outcome updates require agreed behavior. The connector must not promote an unknown state to successful automatically. Preserve references and show the pending condition until verification completes. Compare amounts using the same monetary representation and process refunds according to account permissions. Staff should know when to recheck a payment and when to ask the provider for support. A second charge is not a recovery strategy for an order update problem, so transaction creation and reconciliation must remain distinct operations.

Nexi XPay discovery separates checkout purchases from quote payments or other agreed routes. Give each scenario a specific reference and a visible association with its commercial record. A financial event should not be reduced to a generic comment requiring interpretation. Staff know which state permits the next action and what happens if a flow is abandoned. When integration changes, recheck account-specific instructions. This turns developer-portal options into a documented scope rather than a list of assumed features, while preserving a practical way to reconcile payments originating outside standard checkout.

A furniture store creates a quote and associates it with the agreed payment route. Its reference must not be confused with another online purchase by the same customer. After a verified result, the quote advances to its specified commercial step. An abandoned flow remains pending without false success. Retrying preserves history instead of losing the relationship. Use the actual XPay Greece account instructions rather than assuming every product displayed in the broader developer portal is enabled. Support can then reconcile the quote independently of unrelated checkout orders.

Test two purchases by one customer with different references, abandonment and repeated clicks. Associate the result with the specific commercial record and correct amount. Check that unknown or pending states are displayed without assumed success. Test refunds according to account permissions and instructions. Staff approve who rechecks and who contacts the provider. Confirm production configuration for the selected route with documented exception behavior. The acceptance record should also show that a payment outside standard checkout can be located from its quote and does not silently attach to another open order.