Download the PHP package pronnect/lib-gpwebpay without Composer

pronnect/gpwebpay

PHP library for communicating with the GP Webpay payment gateway.

Supports two independent integration modes:

Requires PHP 8.1+, ext-openssl. SOAP mode additionally needs ext-soap and ext-dom. PSR-3 logger is optional.

Installation

Architecture

The library follows a two-namespace design:

Core flow

1. Create a Config with endpoint, merchant certificates, and provider code.
2. Instantiate Gateway with the config, an optional DigestSigner, and an optional PSR-3 logger.
3. Construct a Request object and call the matching method on Gateway.
4. Gateway auto-fills provider, merchantNumber, messageId from config, signs the request, delegates to WebService (a SoapClient wrapper), verifies the response signature, and returns a typed Response object.

Digest signing

Requests and responses implement SignedInterface. The digest is a |-separated string of specific fields in WSDL-defined order, signed with openssl_sign using the merchant private key, and verified with the GPE public key.

Configuration

Test endpoint: https://test.3dsecure.gpwebpay.com/pay-ws/v1/PaymentService Prod endpoint: https://3dsecure.gpwebpay.com/pay-ws/v1/PaymentService

Usage

Implemented API operations

Token / Card-on-File flow

HTTP API (redirect-based)

The HTTP API is a browser-redirect integration: your server builds a signed URL (or hidden POST form), redirects the cardholder to GP Webpay, and GP Webpay redirects back to your return URL with a signed callback.

HTTP API configuration

Test endpoint: https://test.3dsecure.gpwebpay.com/pgw/order.do Prod endpoint: https://3dsecure.gpwebpay.com/pgw/order.do

Redirect (GET)

POST form

When ADDINFO (3DS2 additional data) is present, the spec requires a hidden POST form instead of a GET redirect:

Processing the return URL callback

GP Webpay redirects back to your return URL with signed GET params. Use HttpGateway::processCallback() for the full flow (signature verification + response object):

Or use the standalone ReturnUrlVerifier if you only need signature checking:

HTTP API constants

VRCODE encryption

HTTP API error handling

SOAP error handling

Errors from the gateway arrive as SoapFault. The serviceException detail is automatically verified and surfaced as a ServiceException (which extends Exception) carrying primaryReturnCode and secondaryReturnCode.

Demo application

A full interactive demo is included in the demo/ directory. It lets you test both API modes against the GP Webpay test gateway using a real merchant certificate — no real charges are made.

Features

• Merchant configuration form (provider, certificate, return URL)
• SOAP WS API: create payment links — direct capture or pre-authorisation; register card token (CoF) or recurring master; refund, capture, auth reversal, recurring charge, CoF re-charge
• HTTP API: create signed redirect orders (GET redirect or POST form), with return URL callback verification
• SQLite payment history with per-payment action panel
• Return URL handler at /return — verifies DIGEST/DIGEST1 signature, updates DB
• Full SOAP request/response logging to stdout (visible in Docker logs)
• Error messages with primary/secondary return code descriptions from resources/xml/codes.xml

Start the demo

Open http://localhost:8080 in your browser.

Set the Return URL in the configuration page to http://localhost:8080/return.

Test cards

Use test cards on the GP Webpay payment page — do not enter real card details.

Full list: developer.globalpayments.com → Test Card Numbers

3D password (if requested): Secure3D

Development

Tests require certificate paths set via environment variables (see phpunit.xml):

WSDL coverage (SOAP)

All 32 active WSDL operations are implemented. processTokenPayment exists in the WSDL but is deprecated by GP Webpay — use processCardOnFilePayment instead.

License

MIT © Pronnect s.r.o.