I'm currently implementing Icepay in #94 which supports token billing.
In the docs (https://github.com/adrianmacneil/omnipay#token-billing) I see that a method createCard() is responsible for storing the token with the provider.

The way I read the Icepay docs, the token is stored with them as part of the initial payment - I think so, at least. The request I am to send them has to include a bunch of payment information.

How would this work with the createCard() thing?

I'd like to ask if possible to implement mass payment with PayPal Payments Pro. It will be very useful to send mass payment from company paypal account to clients paypal accounts via CLI. I found this resource: https://www.x.com/paypal-apis-masspay-php-5.3/nvp
If yes I can fork the library and try to implement it.

Hi guys,

I think there may be a bug on line 21 of Omnipay / SagePay / Message / ServerAuthorizeResponse.php. The isSuccessful() method always returns FALSE – it doesn't seem like this method needs to be implemented because the parent method has it covered.

Is this a bug or am I wrong?

I was just looking at Omnipay, which looks awesome would like to start using it. Is there any plan to support payment providers such as Ukash/Ticketsurf that issue voucher codes rather than having to enter card details?

If you don't have any plans to support these sort of providers I guess it's just a case of creating another interface to support these like: VoucherProviderInterface

Just wondering if it's possible to install and use this without composer.
Not everyone has root access.

Thanks

As discussed in the README, there are two ways we could handle gateway errors:

If there is an error with the payment, an Exception will be thrown. Standard exceptions will be provided, or gateways can define their own exceptions. All payments should be wrapped in a try-catch block:

try {
    $response = $gateway->purchase(1000, $card);
    // mark order as complete
} catch (\Tala\Payments\Exception $e) {
    // display error to the user
}

An alternative to this would be having a response object which indicates the success state. For example:

$response = $gateway->purchase(1000, $card);
if ($response->isSuccessful()) {
    // mark order as complete
} else {
    // display error to the user
}

This method is (arguably) nicer for the end developer, but means we end up writing more boilerplate code in each gateway, because we can not easily do things such as throw an exception inside a nested function if there is a network error, or if the supplied credit card is invalid. Exceptions would also allow each gateway to be more specific about what is causing a particular error, and users could catch specific exceptions and do different things with them.

Since is the most use payment gateway in Latino America would you consider support it in the future?

Hi

I'm running the example app using the SagePay_Server gateway and I seem to have a problem when Sage Pay tries to call the /gateways/{name}/completePurchase route. The Simulator gateway is receiving an exception from Symfony because the transactionId parameter is missing.

I think it's because the paramaters are loaded from the session on line 192 of index.php in the example application and I suspect that as the request is coming from the Sage Pay server (and therefore a different session to the one the paramaters were stored in earlier) it's simply getting an empty array.

If you have any suggestions that would be great, otherwise I'll dig into this further over the weekend.

Thanks!

Tom

I know I can probably learn the lib, add a driver and submit a pull request ... but there is another library (PHP-Payments) that comes baked with Beanstream, so I will likely use that.

Why the example scripts visit the /gateways/**** display 404 Not Found?

how to solve that?

@adrianmacneil what made you decide to change from passing int's as this is what most gateways seem to prefer anyway?

How would I inject extra parameters into the defaults?

For example, I need to be able to send MC_Order, or MC_Customer etc.

Is that possible? Is there a way to dynamically set defaults and then use them in request?

Thank you,

A lot of gateways (maybe all?) provide an error code as well as a message. Have you considered a way of standardising these error codes as much as possible so that rather than having to interpret a message each time one can use a number?

I ask this because I'm receiving an error message back from various gateways and then I can't translate them. What I'm having to do is create a slug from the entire message and use that as an array key in various language files within the framework- obviously this isn't ideal!

Whilst cumbersome, perhaps mapping them to the standard on a per driver basis would suffice?

I'm working on adding CyberSource as payment provider (https://github.com/cvele/omnipay/tree/CyberSource) and would appriciate a bit of help on building unit tests for few methods: Refund, DeleteCard, UpdateCard.

Main problem I have there is that those methods require id to be passed to them and I don't have it.

Would like to avoid mocking responses.

Also, how do you handle api key situations for tests ?

i want to use omnipay in my laravel 4 app

i need to create new Gateway also...

• how can i do that ... should i have to create a new folder in vendor folder or is there any config file which can load some class with a namespace..
• for making it work with laravel 4 should i have to create ServiceProvider.php..??

I always get the error:
"Invalid response from payment gateway"

Even if I use your test example application, I get the same error.

Is it a major bug?

StackTrace:

in D:\work\example\vendor\omnipay\omnipay\src\Omnipay\AuthorizeNet\Message\AIMResponse.php line 29
at AIMResponse->__construct(object(AIMAuthorizeRequest), object(EntityBody)) in D:\work\example\vendor\omnipay\omnipay\src\Omnipay\AuthorizeNet\Message\AbstractRequest.php line 94
at AbstractRequest->send() in D:\work\example\htdocs\index.php line 103
at {closure}('AuthorizeNet_AIM')
at call_user_func_array(object(Closure), array('AuthorizeNet_AIM')) in D:\work\example\vendor\symfony\http-kernel\Symfony\Component\HttpKernel\HttpKernel.php line 129
at HttpKernel->handleRaw(object(Request), '1') in D:\work\example\vendor\symfony\http-kernel\Symfony\Component\HttpKernel\HttpKernel.php line 73
at HttpKernel->handle(object(Request), '1', true) in D:\work\example\vendor\silex\silex\src\Silex\Application.php line 504
at Application->handle(object(Request)) in D:\work\example\vendor\silex\silex\src\Silex\Application.php line 481
at Application->run() in D:\work\example\htdocs\index.php line 284

UPD:

I installed 0.7.1 version and there is no bug. So Authorize.net AIM is broken in 0.8.*.

i have this function for redirecting customers to ccavenue how can i implement that via omnipay

<? 
function ccavenue_gateway($gateway_type, $redirect_url, $order_details)
{

            $WorkingKey = ""  ;
        require("world_libfuncs.php3");
    }
    $Checksum = getCheckSum($Merchant_Id,$order_details['amount'],$order_details['order_id'] ,$Redirect_Url,$WorkingKey);

    ?>

    <!-- Redirect user to cc avenue to make payment -->
<form  name= "ccavenue_redirect" >
    <input type="hidden" name="Merchant_Id" value="<?php echo $Merchant_Id; ?>">
    <input type="hidden" name="Amount" value="<?php echo $order_details['amount']; ?>">
    <input type="hidden" name="Order_Id" value="<?php echo $order_details['order_id']; ?>">
    <input type="hidden" name="Redirect_Url" value="<?php echo $Redirect_Url; ?>">
    <input type="hidden" name="Checksum" value="<?php echo $Checksum; ?>">
    <input type="hidden" name="billing_cust_name" value="<?php echo $order_details['BA']['fname']; ?>">
    <input type="hidden" name="billing_cust_address" value="<?php echo $order_details['BA']['address']; ?>">
    <input type="hidden" name="billing_cust_city" value="<?php echo $order_details['BA']['city']; ?>">
    <input type="hidden" name="billing_cust_state" value="<?php echo $order_details['BA']['state']; ?>">
    <input type="hidden" name="billing_cust_country" value="<?php echo $order_details['BA']['country']; ?>">
    <input type="hidden" name="billing_cust_tel" value="<?php echo $order_details['BA']['mobile1']; ?>">
    <input type="hidden" name="billing_zip_code" value="<?php echo $order_details['BA']['pincode']; ?>">
    <input type="hidden" name="billing_cust_email" value="<?php echo $order_details['BA']['email']; ?>">
    <input type="hidden" name="delivery_cust_name" value="<?php echo $order_details['SA']['fname']; ?>">
    <input type="hidden" name="delivery_cust_address" value="<?php echo $order_details['SA']['address']; ?>">
    <input type="hidden" name="delivery_cust_city" value="<?php echo $order_details['SA']['city']; ?>">
    <input type="hidden" name="delivery_cust_state" value="<?php echo  $order_details['SA']['state'];  ?>">
    <input type="hidden" name="delivery_cust_country" value="<?php echo $order_details['SA']['country']; ?>">
    <input type="hidden" name="delivery_cust_tel" value="<?php echo $order_details['SA']['mobile1'];; ?>">
    <input type="hidden" name="delivery_zip_code" value="<?php echo $order_details['SA']['pincode']; ?>">
<!--    <input type="hidden" name="delivery_cust_notes" value="--><?php //echo $delivery_cust_notes; ?><!--">-->
<!--    <input type="hidden" name="Merchant_Param" value="--><?php //echo $Merchant_Param; ?><!--">-->

</form>

<script language="javascript">
    document.ccavenue_redirect.action="https://www.ccavenue.com/shopzone/cc_details.jsp";
    document.ccavenue_redirect.method="post";
    document.ccavenue_redirect.submit();
</script>

<?
} ?>

The package requires PHP5.3.3 or higher.

The td;dr example code uses PHP 5.4 array constructs.

So which is it? Does this mean PHP5.4 has crept into other parts of the package?

I'm currently working on (and have almost finished) getting SagePay Tokens to work, and also working on a WordPress plugin that wraps the omnipay library and provides a standard way for other plugins to check it's installed and register handlers for notification callbacks.

If anyone has any requirements / thoughts around these areas, pop them in a reply to this message and I'll try to factor them into what I'm doing.

Note: the WordPress plugin is something I'm delivering to a client and so I will be providing commercial support for it, and so I'll be maintaining it to a "professional" standard, so the emphasis with be on stability rather than cutting edge funky :)

Hey,

Just very raw idea, you could use Symfony OptionsResolver component to handle the options definition in gateways.

It's very simple but powerful component. It would allow to define default, required options, check their types, automatically set the defaults if missing and other very cool things.

It also works nicely for gateways which would eventually extend other gateways.

Long story short, it can be used to handle the gateway options in elegant and flexible way.

What do you think?

This is just experience from SagePay Server.

Each address field has valid permitted lengths (min and max) and also sets of characters that are accepted. Being able to access those validation rules from the application to ensure the address and other details are valid, would be useful.

For example, postal codes for SagePay have a maximum length of 10 characters and only accept letters (case-insensitive), digits, spaces and a hyphen. It is also a mandatory field. Anything outside of that will result in a failure when submitted. Catching that before it is sent to SagePay helps in error reporting - the user can be told what is wrong and where, while the error messages that come back from SagePay are not so helpful.

So, are there any thoughts on how this would be implemented? We have solved this in our implementations using a model for the addresses, and then putting validation rules into those. Quite often we find that users need to amend their address, just for the transaction, in order to meet the SagePay validation rules. A good example that comes up a lot in one project is Irish clients who put "N/A" into the postcode field, since the Republic of Ireland does not have postal codes yet. SagePay raises a fatal "invalid character" which means nothing to anyone. In this case it is the "/" that is causing that errror. For other payment gateways that "N/A" may be perfectly acceptable.

I can provide some further examples of what we do practically, if that helps understand where I am coming from. I realise validation cannot all be done before sending to the payment gateway, but if valid acceptable data from these gateways varies a lot, then some of the more obvious validation issues can be caught early.

Hey!

I'm in progress of implementing Braintree gateway.
So if anything should stop me (you have it in works too), please let me know! 😄

As you probably know from @stloyd, we have started some work on Symfony2 integration, I hope to have initial working version by the end of the weekend, but this is just a rough estimation - I'll do my best. You can track the progress here.

I'll probably split this into 2 bundles, one for just Omnipay integration.
And second with more Sylius-specific features.

Thanks for your work!

Bests,
Pawel

Please update information about composer.json here: (https://github.com/adrianmacneil/omnipay/blob/master/example/README.md).

Your Silex example requires more vendors than Omnipay is used:

{
"require": {
"omnipay/omnipay": "0.8.",
"silex/silex": "1.0.@dev",
"twig/twig": "1.12.*@dev"
}
}

Thank you.

Hey guys,
recurring billing is quite important, how come you are not interested in supporting that?

I love you man 👍 This task, especially abstracting away that darn authorize.net library, this does a lot of stuff that I wanted to do myself before.

This is more a question for the project -- has thought been put into the Auth.net CIM gateway? This allows customers to store their credit cards in the Authorize.net system, but unlike what I am seeing for some of the gateways Auth.net requires you to have a customer profile which contains many payment profiles and in order to save/use a saved card you must have both the payment profile and the customer profile id which requires extra parameters to be sent to the gateway.

Another case I am dealing with is being able to enter credit card details, charge a given amount and then also save the credit card in the payment gateway if successful.

I can explain this more and it might be an advanced use case outside the scope of this project but I'm wondering if anyone else has input on Auth.net CIM with Omnipay.

Firstly, Omnipay is awesome! Thanks.

Is there a way built into Omnipay for doing "CrossReferenceTransaction" with CardSave? It is CardSave's way of doing token billing.

Hi,

kudos for this library!

Could you add PayMill gateway to your to-do list?

https://www.paymill.com/

Their apis are very similar to stripe.

Thank you!

I'm implementing a method for Stripe to allow for the retrieval of an existing transaction's details (Docs) and I was wondering what the preferred naming for the new method might be. I'm currently calling it 'retrieve' but am open for suggestions.

I saw in another ticket you're aiming to implement all of the gateways in CI Merchant before taking on board any other gateway requests so I was wondering if you had a roadmap or an estimated timeline for implementation of any of the remaining ones.

I'm keen to use Sagepay with Omnipay and was wondering if you had a plan for when it might be implemented.

Thanks for your time.

This helper method adds 2000 to any two-digit year. So '00' becomes '2000' and '10' becomes '2010'.

Also '99' becomes '2099'. If a card has a start date of "99' (and I know not all cards need a start date, but some do) then it makes more sense that the date is to be interpreted as '1999'.

Of course, all card dates may already be outside this range; I have no idea if there are still current cards issued before 2000, but just raising this in case it has not been considered.

Personally I would add 2000 to the range 0 to 90, and add 1900 to the range 91 to 99, just to widen the window of the lower range of valid years a little.

We have many places where we need an abstract base class, which will be implemented by subclasses. E.g.

• Gateways
• Responses
• Exceptions

Currently we have a standard of GatewayInterface, which is implemented by AbstractGateway, and extended in sub classes named PayPalExpressGateway.

While this is quite verbose (PayPalExpressGateway is already in the Gateway namespace), I basically followed naming conventions I found in Symfony, e.g. Iterator and SessionHandler.

Looking at FuelPHP 2.0, I see the convention is generally to have classes laid out like Session Storage, with a Base class, and no suffix on the subclasses. To me it looks a little weird having hundreds of classes simply called Base in different namespaces, I know this is part of what namespaces are for, and I guess it's more down to personal preference.

Illuminate (PSR-compliant Laravel) tends to follow the Symfony convention, e.g. Grammars.

Also this naming is consistent with things like our Response objects. I'm keen to read any recommendations for class naming conventions - I guess the main thing is we pick one convention and stick to it throughout our codebase.

I found this interesting Drupal thread, where they are standardising on ThingBase for classes not intended to be instantiated directly (whether they are abstract or not), and SpecificThing for sub classes. I like this standard (rather than AbstractThing), it's nice because ThingBase sits next to ThingInterface in the file browser, and also because it doesn't matter if later down the line the class is no longer abstract.

I propose to rename AbstractGateway to GatewayBase, and keep our existing GatewayInterface and PayPalExpressGateway naming convention.

Thoughts?

The payment methods will take an amount (supplied as an integer in the lowest unit, e.g. cents, to avoid floating point
precision issues), a payment source, and an array of extra options, and return a response object:

$card = new CreditCard();
$options = array('returnUrl' => 'https://example.com/payment/complete');
$response = $gateway->authorize(1000, $card, $options); // authorize $10

Alternatively, we could introduce some form of payment request object:

$card = new CreditCard();
$request = new PaymentRequest();
$request->setAmount(1000);
$request->setSource($card);
$request->setReturnUrl('https://example.com/payment/complete');
$response = $gateway->authorize($request);

This provides a cleaner way to set the payment parameters, rather than just passing through an associative array (which some people are seriously against, and parameter arrays doesn't seem to be a very common pattern in PHP, but it's certainly nicer than $obj->method(null, null, null, 'something')).

Perhaps a payment request object is a little overkill though?

To give you an idea, standard parameters which need to be passed through to the payment request are (not including user supplied data, which is stored in the CreditCard object):

• transactionId
• description
• returnUrl
• cancelUrl
• Paypal needs fancy details about tax rates etc
• some form of items array for certain gateways - with a PaymentRequest object we could have a nice addItem() method, rather than an items array inside the $options array

Feedback Wanted: Let me know which option you think provides a nicer API or greater flexibility.

$data['card']['cvc'] = $card->getCvv();

omnipay / src / Omnipay / Billing / Stripe / Gateway.php : 81

I was wondering if that was a typo or expected. I've just started reading the code.

<?php
public function purchase($options)
    {
        $request = new Request($options);
        $request->validate(array('amount'));
        $source = $request->getCard();
        $source->validate(); // here it failes

        return new Response(uniqid());
    }

Expected: Exception with descriptive message or failed response

Hi,

if it's possible, could you please create a new tag for using changes from #53

Thank you.

why is the amount rounded? If I want the decimals?

Great library!

This is as much a question as anything: does this package handle basket/cart data for the gateways? I expect each one will need the data formatted into different structures, and data escaped in different ways, so it makes sense to be able to handle the transactions in a standard structure/object, and perform the relevant formatting in each gateway as required.

This might be a silly question, I've recently started learning about unit tests and phpunit, I can run individual tests from the omnipay directory by using phpunit tests/Omnipay/PayPal/ProGatewayTest.php. These complete just fine but if I try running the whole suite using phpunit from the omnipay directory it seems to get about 26% of the way through (fails on different tests each time, between 195 and 207) then gives:
Fatal error: Cannot redeclare class Mockery_516ff2bd97853 in {...}\omnipay\vendor\mockery\mockery\library\Mockery\Generator.php(129) : eval()'d code on line 1
Any suggestions?

For example in PayPal Express

'PAYMENTREQUEST_0_INVNUM'=>$this->getInvoiceNumber(),
'PAYMENTREQUEST_0_CUSTOM'=>$this->getCustomInfo(),

The comment in DummyGateway says:

 * This gateway is useful for testing. It simply authorizes any payment made using a valid
 * credit card number and expiry.
 *
 * Any card number which passes the Luhn algorithm and ends in 0 is authorized
 * Any card number which passes the Luhn algorithm and ends in 1 is declined

I've tried with valid card 5555557730105001, but it was not failed. Also I cannot find the code related to this logic in the gateway.

I'm curious why Stripe/Gateway.php doesn't include a capture method? I recognize the difference between Omnipay method naming and Stripe method naming described in the docs (https://stripe.com/docs/api#charge_capture). In Stripe, you create a charge, then capture that charge; in Omnipay, you authorize the charge, then capture it.

But it does seem limiting to the end developer and UX functionality to only support purchase in Stripe, especially since the capture method does not have any direct couple to the authorize method. Maybe a create method could be added to the AbstractGateway?

... or more precisely SagePay Direct, simulator and test servers rejecting the card type values Omnipay is sending for Mastercard and Diners Club.

The constants provided for these brands in the Omnipay CreditCard class are "mastercard" and "diners_club", but SagePay appears to accept only "mc" and "diners" (case insensitive).

I can work around this easily by defining my own, very short, CreditCard class

<?php namespace Kuroi\Orders\Models;

/**
 * Reset card types to Sage-acceptable values
 */
class SagePayCreditCard extends \Omnipay\Common\CreditCard
{
    const BRAND_MASTERCARD = 'mc';
    const BRAND_DINERS_CLUB = 'diners';
}

and "using" that instead of the default Omnipay version, but I'm struggling to see an elegant way to override them within the Omnipay Sagepay classes, in such a way as to ensure that they don't get bypassed by apps blindly using the parent CreditCard class.

I'm also wondering why other people aren't going nuts about this. MasterCard and SagePay isn't an uncommon combination on my side of the globe.

I'm hoping to use OmniPay with SagePay\Server and letting SagePay collect the card data.

Right now I'm getting "The card parameter is required" from Omnipay\Common\Message\AbstractRequest.php on line 125.

Am I right in assuming what I'm attempting just isn't possible in OmniPay as it stands? I'm likely to embark on trying to add it if that's the case - but as I'm very new to OmniPay just wanted to check I've not missed something obvious ;)

Cracking library - thanks for sharing

Hi there!
I have a problem when I try calling omnipay like this: http://pastebin.com/V6LMucMb
I get this error: 'RuntimeException [ 60 ]: SSL certificate problem, verify that the CA cert is OK Details: error:14090086:SSL'
Researching a bit about this error, found this solution: http://ademar.name/blog/2006/04/curl-ssl-certificate-problem-v.html, which basically consists on adding 2 lines of code.
This solution worked for me, adding these two lines:

curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, 0);

on the file /buzz/lib/Buzz/Client/Curl.php, just before curl_exec method is getting called.

I'm not sure if this is a Buzz issue, or an Omnipay issue, just wanted to let you know to find out if I'm doing something wrong (and that's why I have to do this to make it work) or it's just like this.

Thanks a lot for this great package!

The README states:

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).

I am implementing a gateway (that I'll be contributing) that uses an off-site redirect. When the user is done on the gateway, he's redirected to a URL of my choice.
Now this API wants me to do a status request to check on the status of the purchase.
So far this all fits in with my mental picture of Omnipay: $gateway->purchase($options) initially and the status request is done within $gateway->completePurchase($options) when the user is redirected back to my URL.

Now this gateway also has out-of-band notification (they connect to a general URL on my site) when a purchase status changes. There of course, I do not have the original $options because the session is not that of the user who made the purchase.
I don't see how I have to fit this in. Should my gateway just have a method updatePurchase that only takes the provided transaction reference, does a status request and go from there?

(Btw, great work being done on this library since I last was involved, sorry I couldn't spare more time for it!)

Hi,

why don't Omnipay send shipping info?
There are many setters and getters for shipping info but when request is send only billing info is used:

    $this->card = new CreditCard();

    $this->card->setAddress1($objShippingAddress->address1);
    $this->card->setAddress2($objShippingAddress->address2);
    $this->card->setFirstName($objBillingAddress->first_name);
    $this->card->setLastName($objBillingAddress->last_name);

    $this->card->setNumber($objOrder->cc);
    $this->card->setExpiryMonth($objOrder->cc_exp_month);
    $this->card->setExpiryYear($objOrder->cc_exp_year);
    $this->card->setCvv($objOrder->cc_code);

    $this->card->setBillingAddress1($objBillingAddress->address1);
    $this->card->setBillingAddress2($objBillingAddress->address2);
    $this->card->setBillingCity($objBillingAddress->city);
    $this->card->setBillingCountry($objBillingAddress->country);
    $this->card->setBillingPostcode($objBillingAddress->zip);
    $this->card->setBillingPhone($objBillingAddress->phone_number);
    $this->card->setBillingState($objBillingAddress->state);

    $this->card->setShippingAddress1($objShippingAddress->address1);
    $this->card->setShippingAddress2($objShippingAddress->address2);
    $this->card->setShippingCity($objShippingAddress->city);
    $this->card->setShippingCountry($objShippingAddress->country);
    $this->card->setShippingPostcode($objShippingAddress->zip);
    $this->card->setShippingPhone($objShippingAddress->phone_number);
    $this->card->setShippingState($objShippingAddress->state);

    $this->card->setCompany($objBillingAddress->business_name);
    $this->card->setEmail($objUser->email);

And the result is:

I believe this is because of code in AIMAuthorizeRequest::getData():

...
return array_merge($data, $this->getBillingData());
...

The second questions about customer ID and customer type fields.

May be it would be nice to implement some basic logic to set fields to $data array, e.g.:

$this->card->setField('x_cust_id', $customerID);

and then use these fields when request is sent.

Current version is not customizable.

What do you think?

I'm working on an e-commerce site and my idea would be to support different types of gateways by using this wonderful library.

Is there a way to know if the selected gateway by the client requires credit card data?
If he chooses to pay with a merchant-hosted gateway, does the gateway implementation expose such information?

Is there any chance to get mobile purchase solution?

I mean implementing https://developer.apple.com/in-app-purchase/ and http://developer.android.com/google/play/billing/billing_overview.html payment methods that store, verify receipts for mobile devices.

Hi just came across this library a few months ago and was wondering could you add support for App55. I use it a lot in some of my projects and would appreciate its inclusion.