Download the PHP package italiamultimedia/xpay-web without Composer

italiamultimedia/xpay-web

PHP library for Nexi XPay Web / Phoenix API-key integrations.

This package targets the API-key based XPay Web endpoints, not the legacy Alias + MAC integration.

Implemented functionality:

• Hosted Payment Page creation: POST /orders/hpp
• Recurring contract creation through Hosted Payment Page recurrence data
• Subsequent recurring payments: POST /orders/mit
• Order status retrieval: GET /orders/{orderId}
• Hosted payment result handling
• Hosted payment notification parsing
• Nexi API error parsing
• Customer-facing Nexi error messages in English and Italian

Installation

The HTTP payment services need:

• a PSR-18 HTTP client
• PSR-17 request and stream factories

For a plain PHP project, one simple combination is:

Frameworks may already provide these services; in that case, pass your framework's PSR implementations instead.

Configuration

You need two values from your application configuration:

• your Nexi API key
• the Nexi environment: test or production

The environment matters because it decides which Nexi API base URL is used:

• Configuration::ENVIRONMENT_TEST uses the Nexi sandbox API
• Configuration::ENVIRONMENT_PRODUCTION uses the live Nexi API

Use the sandbox environment with a sandbox API key. Use the production environment only with a production API key.

Example .env values:

This package does not read .env files directly. Read those values with your framework/configuration layer, then pass them into PaymentSystemSettings.

Plain PHP example:

You can also pass the strings directly:

Using Configuration::ENVIRONMENT_TEST and Configuration::ENVIRONMENT_PRODUCTION is preferred because it avoids typos.

Create Services

Create one DependencyContainer with your payment settings, then use PaymentServiceFactory to build services.

Create A Hosted Payment Page

Create an order in your application first, then send Nexi the hosted payment page request.

Notes:

• correlationId must be a UUID v4.
• orderId should be your local payment/order identifier.
• Amounts are expressed in minor units, so 1000 means EUR 10.00 when using Configuration::CURRENCY.
• resultUrl is where Nexi redirects the customer after payment.
• cancelUrl is where Nexi redirects the customer after cancellation.
• notificationUrl is optional. Pass null unless you have a real public HTTPS webhook listener.
• recurrence is optional. Pass it only when this hosted payment should create a recurring payment contract.

If you do have a webhook listener:

Verify Payment Status

After the customer returns to your resultUrl, do not trust only the redirect parameters. Verify the order through Nexi:

The result redirect may include paymentId, but this library treats your local orderId as the source of truth.

Hosted Result And Notifications

The result URL should already be tied to the local order.

For server-to-server notifications, Nexi posts JSON to your notificationUrl. Parse that received payload and validate it with the security token you stored when creating the hosted payment page:

For notification-only parsing, new DependencyContainer() is enough because payment settings are not needed.

Error Handling

API errors are thrown as NexiApiException.

Supported customer message language codes are en and it. Unknown languages fall back to English.

Recurring Hosted Payments

Nexi recurring payments are MIT payments: Merchant Initiated Transactions. The first customer-present payment creates a contract, then later charges can be made against that contract.

This package supports both phases:

• first payment through Hosted Payment Page with a recurrence object inside CreateHostedPaymentPageRequest
• later merchant-initiated charges through POST /orders/mit

For the first payment, Nexi still receives the same POST /orders/hpp request; the recurrence data tells Nexi to create a contract from the card used on the hosted page.

Use MIT_SCHEDULED when the later merchant charges have a defined schedule, for example every 30 days or on the first day of each month. Nexi also accepts contractExpiryDate and contractFrequency for scheduled contracts.

Use MIT_UNSCHEDULED when the later merchant charges do not have a fixed schedule, for example usage-based or variable-date billing.

Scheduled example:

Unscheduled example:

Store the contractId in your application together with the customer/subscription. Nexi expects it to be unique in your merchant domain.

Subsequent recurring charges are the second phase of Nexi recurring payments and use POST /orders/mit. They are server-to-server calls and do not redirect the customer back to the hosted page.

For subsequent payments:

• correlationId must be a UUID v4.
• idempotencyKey must be a UUID v4 and should be unique for that payment attempt. Reuse the same key only when retrying the same charge after a transport failure.
• orderId is the new merchant order/payment identifier for the recurring charge.
• contractId is the contract created during the first hosted payment.
• captureType is optional. Use CAPTURE_TYPE_IMPLICIT for automatic confirmation or CAPTURE_TYPE_EXPLICIT for authorization only, if your terminal configuration allows it.

Manual Sandbox Scripts

The sandbox scripts do not test server-to-server notifications. To test notification parsing, point notificationUrl at a real listener in your application and pass the received payload to HostedPaymentResultService::parseHostedPaymentNotification().

Development