Download the PHP package ibnnajjaar/mib-global-pay without Composer

MIB Global Pay SDK

A Framework-agnostic PHP SDK for integrating with MIB Global Pay – enabling merchants to initiate payments and retrieve payment statuses using a clean, developer-friendly interface.

This SDK targets the Hosted Checkout integration of the Mastercard Payment Gateway (MPGS).

What is Hosted Checkout? Hosted Checkout is a gateway-managed, PCI-compliant checkout page that you redirect shoppers to for entering payment details. The gateway collects and processes sensitive card data on its own secure pages, then redirects the shopper back to your site with the payment result. This reduces your PCI scope and simplifies compliance while keeping your app focused on order creation and result handling.

Further reading: See the official MPGS Hosted Checkout documentation: https://test-mib.mtf.gateway.mastercard.com/api/documentation/integrationGuidelines/hostedCheckout/integrationModelHostedCheckout.html?locale=en_US

Table of Contents

• Requirements
• Installation
• Setup & Configuration
  • Environment Setup
  • Client Initialization
  • Environment Variables (Recommended)
• Implementation Guide
  • Create Payment
  • Redirect to MIB Checkout
  • Handle Payment Completion
  • Retrieve Payment Status
  • Handling Webhook Data
• Error Handling
• API Response Structures
  • Create Payment Response
  • Payment Status Response
  • Response Methods
• Security Considerations
  • Credential Management
  • HTTPS Requirements
  • Test Card Numbers
• Testing
• Contributing
• Contributors
• License

Requirements

• PHP 7.2 or higher
• Composer

Installation

Install the package using Composer:

Setup & Configuration

Environment Setup

Before using the SDK, obtain your Merchant ID and API Key from the MIB Merchant Portal.

Environment (Sandbox or Production):

Client Initialization

Initialize the client:

Environment Variables (Recommended)

Store credentials securely using environment variables:

Note: NEVER commit your env file to the repository.

Implementation Guide

Create Payment

To initiate a payment, first prepare the order data:

Send the request with the data:

For further information, see the API documentation: Initiate Checkout. Important: Save the successIndicator in your database for later verification after redirection.

Redirect to MIB Checkout

Once you have the session ID, redirect the user to the page below. You will need to update the sandbox.gateway.mastercard.com to the appropriate URL and also send the session ID to the view. This view will automatically redirect the user to the MIB Global Pay payment page.

For further information, see the Documentation: Implementing the Hosted Payment Page.

Handle Payment Completion

After the payment process, MIB will redirect the user to the return_url you provided earlier. On that page, verify the payment result:

For further information, see the Documentation: Interpreting the Response.

Retrieve Payment Status

To double-check the status of a payment via API:

For further information, see the API documentation: Retrieve Order. Best Practice: Always verify payment status with the get order API for critical orders.

Handling Webhook Data

A webhook notifies you of successful transactions at predefined intervals, which is very useful for marking orders as paid. Sometimes, users may close their browser or interrupt the session before the payment gateway returns the transaction information. In such cases, your order might remain marked as unpaid in your database, even though the payment was completed in the merchant portal.

The webhook sends the successful transaction data to a predefined URL. You can use this data to update and mark the order as paid. Additionally, you can set a secret token in the merchant portal that will be included in the webhook request headers. This token can be used to verify the authenticity of the data.

Since webhook notifications are sent as POST requests, your application must be able to accept POST requests at the specified endpoint.

You can convert the webhook data into a response data object as shown below:

For further information, see the Documentation: Webhook Notifications.

Error Handling

The SDK may encounter various errors during API calls. Always implement proper error handling:

API Response Structures

Create Payment Response

This is a typical response you will receive when you send a create transaction request:

Payment Status Response

This is a typical response you will receive to your return URL:

Note: The order ID is present because it was included in the return URL. If you did not include the order ID in the return URL, the order key will not be present.

Response Methods

All responses have the following methods available:

• getStatusCode(): returns int
• getHeaders(): returns an array
• getBody(): returns json string
• toArray(): returns an array
• toDto(): returns a data transfer object defined in the request
• isSuccessful(): returns a boolean
• isFailed(): returns a boolean
• throw(): throws an exception on failed response

Security Considerations

Credential Management

• Store API credentials in environment variables
• Never commit credentials to version control
• Use different credentials for sandbox and production

HTTPS Requirements

• Always use HTTPS for return URLs
• Ensure your checkout page is served over HTTPS
• Verify SSL certificates in production

Test Card Numbers

Use test card numbers provided by the bank. Test cards will be listed in the documentation. Test Cards

Testing

Run tests in Docker

If you prefer to run the test suite in Docker (no local PHP or Composer required):

Changelog

See CHANGELOG.md for release notes: CHANGELOG.md

Contributing

1. Fork the repository
2. Create a feature branch
3. Add tests for new functionality
4. Ensure all tests pass
5. Submit a pull request

Contributors

• Hussain Afeef

License

MIT License.

For additional support, please raise an issue.