Client error response↵[status code] 401↵[reason phrase] Unauthorized↵[url] https://api.demo.globalgatewaye4.firstdata.com/transaction/v14

I am receiving the above error.

Any help will be highly appreciated.

There appears to be no way to submit a transarmor tokenization transaction in the library. I can create a token by submitting a $0 pre-auth and receive it back just fine but I see no way of using that token to complete a transaction. Am I missing something? There is basically nothing on StackOverflow about this.

The PayEezy API does not support the text/html response type. This package depends on that response type. It has worked up to this point. It broke recently in the test mode. The response was URL encoded, but it changed to being HTML encoded and the URL encoded on top of that.

This causes the response data array to have things like [..., 'amp;transaction_approved' => 1, ...] instead of the expected [..., 'transaction_approved' => 1, ...]

I emailed Chris Lord (Payeezy Support [email protected]). After some back and forth he said,

I had a discussion with our level 2 team and application development teams regarding this matter. They advised that the URL encoded content type is not technically an approved message/encoding format. The supported formats are SOAP, XML, and JSON.

This pull request updates the PayEezy gateway to request the JSON response format. With these changed, the package works in test mode again. Until moving to a supported response format, the production mode cannot be trusted, as it could break like the test mode any time.

Based on the following snippets, it seems to me like it isn't:

class CompletePurchaseRequest extends PurchaseRequest
{
    public function sendData($data)
    {
        return $this->response = new CompletePurchaseResponse($this, $data);
    }

class PurchaseResponse extends AbstractResponse implements RedirectResponseInterface
{
    public function isSuccessful()
    {
        // FIXME: This makes no sense.
        return false;
    }

As far as I can see, the FirstData_Connect gateway never issues a post request. It just creates a response object using the request data.

Am I missing something? Otherwise it would be good to remove it from the readme.

I'm not really sure if how I did this fits with the "way things are done" around here, but it works, its a needed feature so if its acceptable please merge it or if not, feel free to re-implement it the way you want it implemented.

Basically I just had to add getTokenCardType() and setTokenCardType() to PayeezyPurchaseRequest, which allows the user to supply a "tokenCardType" parameter when calling $gateway->purchase() or $gateway->authorize(). tokenCardType is required and must match a valid card type found in \omnipay\common\CreditCard. The user must also supply the built in cardReference parameter with the desired card token.

The CreditCard parameter must contain the cardholder name supplied by which ever field works for the user name billingName or whatever firstName / lastName fields they want. The card Expiration date must also be supplied.

There is a usage example added to the comments in PayeezyPurchaseRequest.php

This fixes https://github.com/thephpleague/omnipay-firstdata/issues/9

My pull request was merged 4 months ago, however today I ran a composer update - and it blew out all of my edits and brought my site down temporarily.

I had to manually paste over the update code with my previous code.

This repo reflects the correct code but composer update does not....

Global Gateway has a parameter called transaction_tag that is used to identify the original transaction you want to modify for a prior-auth capture, void or refund. From what I've seen in other Omnipay gateways, that should be the parameter used for the transactionReference property. In keeping with that pattern, I changed the method getTransactionReference to return transaction_tag, and added a method getAuthorizationCode which returns the authorization_num response, similar to how the Authorize.net gateway works.

Other than that, the refund functionality should be straightforward.

Cheers!

Support for First Data Global Gateway e4. docs

Based on https://github.com/a2nt/Omnipay-First-Data-Global-Gateway-E4 with cleanups and tests finished.

Added getTransactionId() method and corrected what getTransactionReference() returns.

OmniPay convention states that transactionId is 'our' reference (which is held in 'oid') and transactionReference should be 'their' ID (which is held in 'refnumber').

This pull request updates Omnipay to v3 and makes the necessary changes to the package to comply with the update.

Based on changes made in thephpleague/omnipay-firstdata#22

My credentials are working using v2.3 of this project but not v 2.4

I'm noticing that if I echo out my hmac string just before the request is sent, it is empty. This seems to be a difference between 2.3 and 2.4. Version 2.3 does not have hmac, and it uses API version 11 instead of 14.The documentation does not mention initializing the hmac at all, or there being a key.

Is there something I'm missing? Perhaps I'm misreading the documentation.

I am using this package for a Laravel project 7.x, When upgrading to Laravel 8, it requires guzzlehttp/guzzle 7.x while php-http/guzzle6-adapter requires guzzlehttp/guzzle 6.x. Do we have any plans to support guzzlehttp/guzzle 7.x for this package?

https://github.com/php-http/guzzle6-adapter/pull/72 https://github.com/php-http/discovery/pull/189

My company needed to add Telecheck capabilities so I forked and upgrade this package. I'm not sure if this is still being actively maintained but I figured i should give you the option to merge what I've done back in.

I added and ACH object that can replace the CreditCard Object and allow people to easily use Telecheck instead of a credit card. I also made sure to write tests for ACH and any other additions I added.

PayeezePurchaseResponse and PayeezePurchaseRequest were the most heavily updated mainly just additions to handle ACH.

If there is anything you need to merge this in let me know.

I don't know if this library is still being maintained or not but in case anyone else runs into this maybe I can save you from busting your head open against a wall like I did.

The packaged version of guzzle that this lib depends upon has included its own cacert.pem file which it stores in vendors/guzzle/guzzle/src/Guzzle/Http/resources/cacert.pem

This ca is old and not valid for the new first data / payeezy certificates and will throw a CURL 60 SSL error whenever you try to use this library.

I cannot see any way in the configuration to override this behavior from my code without manually overriding code in this library.

I am going to fork this library to fix this for myself. If the fix I come up with would work for the production code I'll supply a PR but I'm up against a time constraint on this so I'm not going to spend a lot of time on this.

Is this repo still supported?

I'm trying to implement it and added it to my Laravel installation with Omnipay. When I attempt to make payment through the system it just hangs up. I went into my Payeezy sandbox account and it shows a way different URL than what is showing in the Message/PurchaseRequest.php file for test mode and even live mode.

Is there any chance someone can update the repo with the latest functionality of Payeezy?