thephpleague / omnipay

A framework agnostic, multi-gateway payment processing library for PHP 5.6+
http://omnipay.thephpleague.com/
MIT License
5.91k stars 925 forks source link

Sending Card Number Directly Not Acceptable #692

Open Keram-Yasin opened 11 months ago

Keram-Yasin commented 11 months ago

Hello everyone,

I encountered an issue while integrating Omnipay with Stripe. After I have put down the exact same code in README.MD page with my test API Key. I had following error after checkout:

"Sending credit card numbers directly to the Stripe API is generally unsafe. We suggest you use test tokens that map to the test card you are using, see https://stripe.com/docs/testing."

I had no way to solve the problem unless I follow the integration guide of Stripe meaning I have to totally give up on this repository.

Is there any trick to stick to this repository which is super handy?

lfjeff commented 11 months ago

I encountered the same problem when using Stripe and and fixed it by first calling Stripe to “create a customer” and get a token. This adds an extra step, but only takes a few extra milliseconds for the API call.

Then we use the token to continue processing normally.

It’s been a few years, so I don’t remember all the details right now, but we’re still using Omnipay with Stripe to process transactions where we have the customer’s card number. With our particular use case, we do not interact directly with the card holder, another third-party system accepts the customer’s card details and passes the information to us for processing.

If you have not already done so, it may be helpful to create your own wrapper class around Omnipay. This will make it easier to make customizations like this without having to hack the Omnipay code. I have my own credit card processing classes, which are based mostly on Omnipay. So far, I’ve used it to support several different gateways (Authorize.net http://authorize.net/, PayPal, Stripe, and a few others). The only one I have not been able to use is Square, because they simply do not allow you to directly handle the customer’s credit card number. They force you to use their Javascript plugin, which then returns a token.

On Aug 3, 2023, at 1:12 AM, Keram Yasin @.***> wrote:

Hello everyone,

I encountered an issue while integrating Omnipay with Stripe. After I have put down the exact same code in README.MD page with my test API Key. I had following error after checkout:

"Sending credit card numbers directly to the Stripe API is generally unsafe. We suggest you use test tokens that map to the test card you are using, see https://stripe.com/docs/testing https://stripe.com/docs/testing."

I had no way to solve the problem unless I follow the integration guide of Stripe meaning I have to totally give up on this repository.

Is there any trick to stick to this repository which is super handy?

— Reply to this email directly, view it on GitHub https://github.com/thephpleague/omnipay/issues/692, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4MHFVQVGJCPFBHPF4PFP3XTNMQRANCNFSM6AAAAAA3CMHOPY. You are receiving this because you are subscribed to this thread.

Keram-Yasin commented 11 months ago

I collected the card holder's data directly in my web app which is still in test phase. And I figured out that this is not a safe and standard way to deal with customers. I used that way because some other payment service provider offers php API which charges customers directly on the backend after passing customer data from front-end.

Furthermore the payment gateways can not charge customers with one step or one click because customers are most likely to be redirected after $gateway->purchase() action.

Considering all the information, I gave up the easy but insecure way of collecting customer information method, thus I adopted the standard way of leave-custome- data-to-payment-provider method. This way all parties involved would be happy about the transaction.

lfjeff commented 11 months ago

If you’re using a web app with a gateway-provided widget to collect the cardholder data, you should still be able to use Omnipay to handle things. This places the burden of security on the gateway and lets you avoid all the PCI requirements.

I believe that many of the Omnipay gateway-specific libraries are designed to work with a gateway-provided interface widget to generate a token that is passed back to the Omnipay for further processing.

Omnipay is very useful if you need to support multiple gateways, but if you’re only using Stripe and never plan to use anything else, then it might be simpler to just use the Stripe SDK.

On Aug 3, 2023, at 12:56 PM, Keram Yasin @.***> wrote:

I collected the card holder's data directly in my web app which is still in test phase. And I figured out that this is not a safe and standard way to deal with customers. I used that way because some other payment service provider offers php API which charges customers directly on the backend after passing customer data from front-end.

Furthermore the payment gateways can not charge customers with one step or one click because customers are most likely to be redirected after $gateway->purchase() action.

Considering all the information, I gave up the easy but insecure way of collecting customer information method, thus I adopted the standard way of leave-custome- data-to-payment-provider method. This way all parties involved would be happy about the transaction.

— Reply to this email directly, view it on GitHub https://github.com/thephpleague/omnipay/issues/692#issuecomment-1664571484, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4MHFUDWXY2J4D4TI3HR5LXTP66NANCNFSM6AAAAAA3CMHOPY. You are receiving this because you commented.

Keram-Yasin commented 11 months ago

Your advice is really reasonable. I would be cosidering very well if that would be great fit to my web app. Thanks for your kind reply and advices. You're very helpful.