I'm using rails 3.2.6, and Stipe for payment. Is There any possibility to make a payment with out purchasing ssl certificate. Can i use Stripe page as my payment page?
You can technically skip SSL by using stripe.js but I highly suggest you set up SSL.
What it does is pass credit card information directly to stripe and then stripe will give you a token to use to actually make the charge. Doing it that way means that credit card information never touches your server and you don't have to worry about PCI compliance. However you should still set up SSL to prevent man in the middle attacks.
You can find a good tutorial about how to do this at https://stripe.com/docs/tutorials/forms
There is also an episode on railscasts which explains it more in depth.
Stripe doesn't provide any sort of hosted form. So unless you have someone else host your payment form over SSL (for example, using one of the pre-built integrations), then you'll need to serve your form over SSL. More details on the requirement here.
Related
When would you choose confirmCardPayment in the front end and when would you choose paymentIntent.Confirm in the backend?
currently our app allows you to checkout as guest, save a credit card if you are not a guest or use a saved card.
All of these flows work without confirmcardpayment on the frontend and without the paymentintent.confirm on the backend
I'm guessing there will be a time where a card payment requires extra authentication and that is when we need to either confirm in the front end or conifrm in the backend? (Also, when/why would a card require extra authentication? New to this space and looking to learn)
Our code pretty much follows this: https://github.com/stripe-samples/saving-card-after-payment/blob/master/without-webhooks/server/go/server.go
PS: The TLDR from the above link is:
Front end:
Creates a paymentmethod with a given card or saved card.
Sends POST /pay API to backend
Backend:
Receives API (validates if user is auth or not - in our case)
Creates a payment intent to be sent to stripe with paymentmethodID from frontend AND customerID gotten from our backend (Stripe's customer id that we created beforehand)
Stripe returns us the paymentmethod with status.
No confirmation on either front.
If same payment method tries to get used for another customer, fails.
If same payment method gets used for same customer (Saved card behavior) it works.
I'm guessing there will be a time where a card payment requires extra authentication and that is when we need to either confirm in the front end or conifrm in the backend?
You need to do this on the frontend because of customer authentication yes. Confirming on the frontend attempts the payment, and the Stripe JS library will also present any additional UI needed like the customer's bank's 3D Secure authentication page.
That is also important for accepting other types of payment methods(which you should, as having more local payment methods in your checkout flow increases customer conversion). E.g., payments using iDEAL require a redirect to the customers bank which again is handled on the client side. https://stripe.com/docs/payments/ideal#payment-flow
(Also, when/why would a card require extra authentication? New to this space and looking to learn)
Pretty much any transaction in Europe and the UK requires 3D Secure authentication right now, and it's only becoming more prevalent worldwide
https://stripe.com/docs/strong-customer-authentication
https://stripe.com/docs/payments/3d-secure
https://support.stripe.com/questions/strong-customer-authentication-sca-enforcement-date
Our code pretty much follows this
The Github link/flow you linked is an alternative way of using Stripe where you attempt the payment on the backend and then need to do a round-trip if authentication is required , but it's generally preferred to use client-side confirmation as it's more scalable for accepting other payment methods. See the notes on
https://stripe.com/docs/payments/accept-a-payment-synchronously
I'm hoping discuss how to use Magento 2 and Authorize.net in a way that removes most the PCI compliance risk. The Magento 2 Direct Post Method (DPM) appears to still contain a high level of risk and requirements. Our setup: Authorize.net was setup by our bank and had us use TrustWave to validate our PCI risk/compliance. We are currently using Authorize.net as the payment gateway and using the Out-Of-The-Box Authorize.net DPM module.
One of the questions in the TrustWave questionnaire asks:
Do the web servers you administer have control over the payment page that is presented to your customers?
I answered Yes - some or all of the payment page is generated from my website; since the Magento 2 system generates the Credit Card form in the vendor/magento/module-authorizenet/view/frontend/web/template/payment/authorizenet-directpost.html file which calls the Magento_Payment/payment/cc-form template.
Because of this answer, if I understand this correctly, we need to be fully PCI compliant.
Is there a way to use Magento 2 and Authorize.net without generating the payment form on our webserver? We are trying to limit our PCI risk while being able to be paid (snarky comments welcome).
Thanks in advance.
Authorize.net has deprecated the DPM api. See: https://developer.authorize.net/api/upgrade_guide/
They suggest using the Accept.js method now as a replacement. https://developer.authorize.net/api/reference/features/acceptjs.html
I've been working on a secure shopping cart and checkout for a website. I'm using PayPal, and I'd read that PCI requirements aren't as much of an issue if we don't store card data on our site, so if possible I'd like to avoid that.
HTML buttons seemed like a promising option, but upon further investigation, it seems like maintaining control of active user sessions may not be possible. Below are my sources that seem to confirm this.
PayPal button return url usage
delete session variables when session id is known but not able to start session
PayPal payments pro is mentioned in the second post, but I'm wondering if it or anything else meets my 2 design constraints as they're implications for the implementation don't seem to gel very well.
If they are losing session data when returned from PayPal with a standard button then they have something else going wrong. That should not be happening.
That said, if you're comfortable working with APIs I always recommend Express Checkout and Payments Pro.
If you prefer REST APIs you can use that for PayPal payments and direct credit card payments.
If you prefer NVP / SOAP you can use the Classic API.
In any case, keeping session data alive won't be an issue, and as you mentioned, as long as you aren't storing any credit card data on your server in log files, in the database, or anywhere then you won't have to worry about PCI compliance.
I am working on an app that requires payment to be collected from customers. I have few questions related to braintree integration with my app. I am actually struggling a bit with the workings of the braintree so thought of checking here.
The PCI compliance is critical so i do not want to store anything in my app or the backend server. Can I achieve this with braintree? I also don’t want customer to retype the credit card information when they come back to the app. As I understand there is a Vault functionality which can do this but I was not sure.
Do I invoke the braintree API from iOS app directly or do I need to first send the credit card information to my backend layer and then invoke the Braintree APIs from backend. I don’t want to transmit anything to my server due to the PCI compliance so I am hoping that I can just invoke the braintree API directly from the iOS APP and when user comes back, again invoke the braintree Vault API from the APP and pull the previously used credit card.
appreciate if anyone can pls. direct me to some kind of architecture / white paper/best practice on this. I went thru the APIs document on braintree site which provides and good API documents but i could not find the high level architecture document on this.
Thanks in advance..
Yes. https://articles.braintreepayments.com/control-panel/vault/overview
Yes use from iOS. https://developers.braintreepayments.com/ios+ruby/start/hello-client
for number three... I'm not sure where to find that. Definitely ask support
We are upgrading our SagePay protocol from v2.23 to 3.0 to support surcharge fees. In v3.0 transaction registration post there are CreateToken and StoreToken which was not in the earlier version. What is the reason for create and store tokens? I went through the document but couldn't find a clue.
The link provided in the above post links to advice by one of our Sage Pay Partners so take a look at it.
Token allows shoppers the option of storing their card details (as a token) to their account on the payment page during their first purchase instead of having to set it up manually afterwards. Single click purchases for repeat customers will become much simpler and quicker to set up.
To view the Token Guide go to here, scroll to the bottom of the screen and select the Download the Documents option within your preferred method of integration (server, server inframe, direct). Within the guide it explains creating and storing a token.
If this is a service you would like enabled on your Sage Pay account our New Business team are available 0900-1800 on 0845 111 4466. Prices for Token are available via here. If you have any other questions, our 24/7 Support team can assist to on 0845 111 4455.
Sage Pay Support.
I believe this is related to their token system, allowing you to store and send card details as a token.
If you don't use their token system you don't need to worry about it.
Sage Pay have destroyed their content recently so it's hard to find anything, here's a quick article on their token system - http://www.metakinetic.com/blog/2013/09/sage-pays-token-system-and-advancements-in-payment-gateways/