Download the PHP package mmockelyn/payment without Composer

THIS PACKAGE IS NOT MAINTAINED ANYMORE

Accept payments from payment gateways

This Laravel package enables you to accept payments from payment gateways. Currently the only implementation is Europabank.

Spatie is a webdesign agency in Antwerp, Belgium. You'll find an overview of all our open source projects on our website.

Postcardware

You're free to use this package (it's MIT-licensed), but if it makes it to your production environment you are required to send us a postcard from your hometown, mentioning which of our package(s) you are using.

Our address is: Spatie, Samberstraat 69D, 2060 Antwerp, Belgium.

The best postcards will get published on the open source page on our website.

Installation

The package can be installed through Composer:

This service provider must be installed:

Configuration

You can publish the configuration file using this command:

A configuration-file with some sensible defaults will be placed in your config/packages directory:

General payment flow

Though there are multiple ways to pay an order, most payment gateways except you to follow the following flow in your checkout process:

1. The customer is redirected to the payment provider

After the customer has gone through the checkout process and is ready to pay, the customer must be redirected to site of the payment provider.

The redirection is accomplished by submitting a form with some hidden fields. The form must post to the site of the payment provider. The hidden fields minimally specify the amount that must be paid, the order id and a hash.

The hash is calculated using the hidden form fields and a non-public secret. The hash used by the payment provider to verify if the request is valid.

2. The customer pays on the site of the payment provider

The customer arrived on the site of the payment provider and gets to choose a payment method. All steps necessary to pay the order are taken care of by the payment provider.

3. The customer gets redirected back

After having paid the order the customer is redirected back. In the redirection request to the shop-site some values are returned. The values are usually the order id, a paymentresult and a hash.

The hash is calculated out of some of the fields returned and a secret non-public value. This hash is used to verify if the request is valid and comes from the payment provider. It is paramount that this hash is thoroughly checked.

The payment result can be something like "payment ok", "customer cancelled payment" or "payment declined".

Usage

This package can greatly help you with step 1. and 3. of the general flow

1. Redirecting to customer to the payment provider

Let's get technical. In the controller in which you will present a view to redirect to user to the payment provider you must inject the payment gateway like so:

In the same controller in the method in which you present the view you must set the that you've probably build up during the checkout-process.

The you pass to the payment gateway must adhere to the -interface:

So your Order-model should look something like

Please note that for most payment providers the result of should be specified in eurocents.

After you've taken care of all steps above you can generate the form that will redirect the customer to the payment provider.

In your view you can simply use the -method

The result of this form is something like:

When clicking the submit button the customer gets redirected to the site of payment provider.

You can also pass html attributes for the form element as an array.

2. Verifying the payment

So now we've redirected the customer to the payment provider. The customer did some actions there (hopefully he or she paid the order) and now gets redirected back to our shop site.

The payment provider will redirect the customer to the url of the route that is specified in the -option of the config-file.

We must validate if the redirect to our site is a valid request (we don't want imposters to wrongfully place non-paid order).

In the controller that handles the request coming from the payment provider inject the

Then, in the same controller, in the method you use to handle the request coming from the payment provider, use the -method:

That method requires the order id that you are expecting a payment for. Usually you should have stored that order id in session prior to redirecting to user to the site of payment provider.

Notice that in previous example is used. If you want such an elegant syntax check out the spatie/checkout-package.

If the -method concludes that the request was not valid a -exception is thrown.

3. Getting the payment result

After you've verified that the redirect from the payment provider to your site is valid you can determine the result of the payment.

To determine the result you can use the -method. It can return these constants:

• : all is well, the order has been paid
• : the customer has cancelled the payment
• : the customer tried to pay, but his payment got declined by that financial institution that handles the payment
• : an unexpected error occured.

Here is an example controller in which we verify the payment-request and determine the result:

Remarks

Currently the only implemented gateway provider is Europabank. They can give feedback on a payment in many different ways, but this package only supports the 'DIRECT'-redirecttype.

The Europabank API has many more options than this package currently provides.

All the examples above are coded to an interface: it should be fairly easy to swap out Europabank and use an other provider like Ingenico. You most certainly are welcome to send pull requests to implement other providers.

About Spatie

Spatie is a webdesign agency in Antwerp, Belgium. You'll find an overview of all our open source projects on our website.