Content

Cached Text (at the time of saving)


An easy to use, consistent payment processing library for PHP 5.3+
Omnipay is a payment processing library for PHP. It has been designed based on ideas from Active Merchant , plus experience implementing dozens of gateways for CI Merchant . It has a clear and consistent API, is fully unit tested, and even comes with an example application to get you started.
Why use Omnipay instead of a gateway's official PHP package/example code?
Because you can learn one API and use it in multiple projects using different payment gateways
Because if you need to change payment gateways you won't need to rewrite your code
Because most official PHP payment gateway libraries are a mess
Because most payment gateways have exceptionally poor documentation
Because you are writing a shopping cart and need to support multiple gateways
Important Note: Upgrading from <2.0
If you are upgrading from a pre-2.0 version of Omnipay, please note that the project has now been split into multiple packages. There have also been some changes to how gateway instances are created. See the full release notes for more details.
TL;DR
Just want to see some code?
use Omnipay\Omnipay ; $gateway = Omnipay :: create ( 'Stripe' ); $gateway -> setApiKey ( 'abc123' ); $formData = [ 'number' => '4242424242424242' , 'expiryMonth' => '6' , 'expiryYear' => '2016' , 'cvv' => '123' ]; $response = $gateway -> purchase ([ 'amount' => '10.00' , 'currency' => 'USD' , 'card' => $formData ]) -> send (); if ( $response -> isSuccessful ()) { // payment was successful: update database print_r ( $response ); } elseif ( $response -> isRedirect ()) { // redirect to offsite payment gateway $response -> redirect (); } else { // payment failed: display message to customer echo $response -> getMessage (); }
As you can see, Omnipay has a consistent, well thought out API. We try to abstract as much as possible the differences between the various payments gateways.
Package Layout
Omnipay is a collection of packages which all depend on the omnipay/common package to provide a consistent interface. There are no dependencies on official payment gateway PHP packages - we prefer to work with the HTTP API directly. Under the hood, we use the popular and powerful Guzzle library to make HTTP requests.
New gateways can be created by cloning the layout of an existing package. When choosing a name for your package, please don't use the omnipay vendor prefix, as this implies that it is officially supported. You should use your own username as the vendor prefix, and append -omnipay to the package name to make it clear that your package works with Omnipay. For example, if your GitHub username was santa , and you were implementing the giftpay payment library, a good name for your composer package would be santa/giftpay-omnipay .
If you want to transfer your gateway to the omnipay GitHub organization and add it to the list of officially supported gateways, please open a pull request on the omnipay/common package. Before new gateways will be accepted, they must have 100% unit test code coverage, and follow the conventions and code style used in other Omnipay gateways.
Installation
Omnipay is installed via Composer . To install all officially supported gateways, simply add the following to your composer.json file:
Alternatively, you can require individual gateways:
Next, run composer to update your dependencies: $ curl -s http://getcomposer.org/installer | php $ php composer.phar update
Payment Gateways
All payment gateways must implement GatewayInterface , and will usually extend AbstractGateway for basic functionality.
The following gateways are available and officially supported:
Gateways are created and initialized like so:
Most settings are gateway specific. If you need to query a gateway to get a list of available settings, you can call getDefaultParameters() :
Generally most payment gateways can be classified as one of two types:
Off-site gateways such as PayPal Express, where the customer is redirected to a third party site to enter payment details
On-site (merchant-hosted) gateways such as PayPal Pro, where the customer enters their credit card details on your site
However, there are some gateways such as Sage Pay Direct, where you take credit card details on site, then optionally redirect if the customer's card supports 3D Secure authentication. Therefore, there is no point differentiating between the two types of gateway (other than by the methods they support).
Credit Card / Payment Form Input
User form input is directed to an CreditCard object. This provides a safe way to accept user input.
The CreditCard object has the following fields:
firstName
lastName
number
expiryMonth
expiryYear
startMonth
startYear
cvv
issueNumber
type
billingAddress1
billingAddress2
billingCity
billingPostcode
billingState
billingCountry
billingPhone
shippingAddress1
shippingAddress2
shippingCity
shippingPostcode
shippingState
shippingCountry
shippingPhone
company
email
Even off-site gateways make use of the CreditCard object, because often you need to pass customer billing or shipping details through to the gateway.
The CreditCard object can be initialized with untrusted user input via the constructor. Any fields passed to the constructor which are not recognized will be ignored.
You can also just pass the form data array directly to the gateway, and a CreditCard object will be created for you.
CreditCard fields can be accessed using getters and setters:
If you submit credit card details which are obviously invalid (missing required fields, or a number which fails the Luhn check), InvalidCreditCardException will be thrown. You should validate the card details using your framework's validation library before submitting the details to your gateway, to avoid unnecessary API calls.
For on-site payment gateways, the following card fields are always required:
firstName
lastName
number
expiryMonth
expiryYear
cvv
You can also verify the card number using the Luhn algorithm by calling Helper::validateLuhn($number) .
Gateway Methods
The main methods implemented by gateways are:
authorize($options) - authorize an amount on the customer's card
completeAuthorize($options) - handle return from off-site gateways after authorization
capture($options) - capture an amount you have previously authorized
purchase($options) - authorize and immediately capture an amount on the customer's card
completePurchase($options) - handle return from off-site gateways after purchase
refund($options) - refund an already processed transaction
void($options) - generally can only be called up to 24 hours after submitting a transaction
On-site gateways do not need to implement the completeAuthorize and completePurchase methods. If any gateway does not support certain features (such as refunds), it will throw BadMethodCallException .
All gateway methods take an $options array as an argument. Each gateway differs in which parameters are required, and the gateway will throw InvalidRequestException if you omit any required parameters. All gateways will accept a subset of these options:
card
token
amount
currency
description
transactionId
clientIp
returnUrl
cancelUrl
Pass the options through to the method like so:
When calling the completeAuthorize or completePurchase methods, the exact same arguments should be provided as when you made the initial authorize or purchase call (some gateways will need to verify for example the actual amount paid equals the amount requested). The only parameter you can omit is card .
To summarize the various parameters you have available to you:
Gateway settings (e.g. username and password) are set directly on the gateway. These settings apply to all payments, and generally you will store these in a configuration file or in the database.
Method options are used for any payment-specific options, which are not set by the customer. For example, the payment amount , currency , transactionId and returnUrl .
CreditCard parameters are data which the user supplies. For example, you want the user to specify their firstName and billingCountry , but you don't want a user to specify the payment currency or returnUrl .
The Payment Response
The payment response must implement ResponseInterface . There are two main types of response:
Payment was successful (standard response)
Website requires redirect to off-site payment form (redirect response)
Successful Response
For a successful responses, a reference will normally be generated, which can be used to capture or refund the transaction at a later date. The following methods are always available:
In addition, most gateways will override the response object, and provide access to any extra fields returned by the gateway.
Redirect Response
The redirect response is further broken down by whether the customer's browser must redirect using GET (RedirectResponse object), or POST (FormRedirectResponse). These could potentially be combined into a single response class, with a getRedirectMethod() .
After processing a payment, the cart should check whether the response requires a redirect, and if so, redirect accordingly:
The customer isn't automatically forwarded on, because often the cart or developer will want to customize the redirect method (or if payment processing is happening inside an AJAX call they will want to return JS to the browser instead).
To display your own redirect page, simply call getRedirectUrl() on the response, then display it accordingly:
Error Handling
You can test for a successful response by calling isSuccessful() on the response object. If there was an error communicating with the gateway, or your request was obviously invalid, an exception will be thrown. In general, if the gateway does not throw an exception, but returns an unsuccessful response, it is a message you should display to the customer. If an exception is thrown, it is either a bug in your code (missing required fields), or a communication error with the gateway.
You can handle both scenarios by wrapping the entire request in a try-catch block:
Token Billing
Token billing allows you to store a credit card with your gateway, and charge it at a later date. Token billing is not supported by all gateways. For supported gateways, the following methods are available:
createCard($options) - returns a response object which includes a cardReference , which can be used for future transactions
updateCard($options) - update a stored card, not all gateways support this method
deleteCard($options) - remove a stored card, not all gateways support this method
Once you have a cardReference , you can use it instead of the card parameter when creating a charge: $gateway->purchase(['amount' => '10.00', 'cardReference' => 'abc']);
Recurring Billing
At this stage, automatic recurring payments functionality is out of scope for this library. This is because there is likely far too many differences between how each gateway handles recurring billing profiles. Also in most cases token billing will cover your needs, as you can store a credit card then charge it on whatever schedule you like. Feel free to get in touch if you really think this should be a core feature and worth the effort.
Example Application
An example application is provided in the omnipay/example repo. You can run it using PHP's built in web server (PHP 5.4+): $ php composer.phar update --dev $ php -S localhost:8000
For more information, see the Omnipay example application .
Support
If you are having general issues with Omnipay, we suggest posting on Stack Overflow . Be sure to add the omnipay tag so it can be easily found.
If you want to keep up to date with release anouncements, discuss ideas for the project, or ask more detailed questions, there is also a mailing list which you can subscribe to.
If you believe you have found a bug, please report it using the GitHub issue tracker for the appropriate package, or better yet, fork the library and submit a pull request.
Feedback
Please provide feedback! We want to make this library useful in as many projects as possible. Please head on over to the mailing list and point out what you do and don't like, or fork the project and make suggestions. No issue is too small.