I created customer in Stripe with Elements. Now I need to check if customer exists in my web app (with axios request). As far as I know the only way to check if customer exists is to retrive him: https://stripe.com/docs/api/customers/retrieve.
I don't want customer's card information to be present in my app because of PCI compliance. But https://stripe.com/docs/api/customers/retrieve API gives card information in response. Is there any method which checks customer's status?
Thank you!
If you use the stripe provided card collection functionality then the actual card details will not be sent to your server instead stripe handles it and then provide you a token which we cannot reverse to all card details. After that all the data stripe api is returning can be stored on your server. Since it doesn't contain any credentials which can be used to charge the card without Secret key stored in your server.
https://stripe.com/docs/security
Regarding what data you want to show on your front end:
When you are sending request to your server from front end (and server checks customer with stripe api), in response from your server you can omit any information which you don't want to send to your front end. So essentially what you will be doing is that only restrict user to only their customer data you have on your server.
Related
I am implementing subscriptions to a premium service on a website using Paypal as the payment service. I have successfully created a Catalog Product and Billing Plan through the API, and I am able to get to the payment page on Paypal, but it's not clear how I'm supposed to persist a user identifier through the purchase process.
I assumed it would be something along the lines of passing a user id somewhere, but there's nothing in the Paypal documentation about this. I need to be able to let the user make a purchase and have the Paypal webhook send the confirmation to an endpoint on my site, and that's where I'd expect to get their user id to toggle the subscription on their account on my end.
Is there something I'm missing? There has to be a way to do this cause I'd imagine it's a pretty common use case. If anyone has information or has done this before, I'd love to hear. Thanks.
The only truly secure way I've found when using javascript SDK, is to securely generate a unique custom_id on your server side associated with the user.
Then when you create the buttons, the 'createSubscription' function takes custom_id as a parameter.
Then use a webhook to receive events from your subscription and the custom_id will be present in the body of all BILLING.SUBSCRIPTION events under resource.custom_id.
I am able to get to the payment page on PayPal,
You are vague about what you are doing here. There are multiple ways (and some ways have multiple versions) of accepting subscriptions via PayPal, so it is important that you provide full details about the method you are using.
The time to associate a created subscription ID with a user ID is when it is approved, in the onApprove function if you are using a Smart Payment Button: https://developer.paypal.com/docs/subscriptions/integrate/#4-create-a-subscription
I have designed a app. I have questions regarding customer/data_request webhooks
In what format does Shopify expect app developers to respond to these webhooks?
Should our response be sent back to the merchant's email (even though the customer requested this data)?
As mentioned in the Shopify documentation when a customer requests their data from a store owner, Shopify sends a payload on the customers/data_request topic to the apps installed on that store. If your app has been granted access to customers or orders, then you receive a data request webhook with the resource IDs of the data that you need to provide to the store owner. It's your responsibility to provide this data to the store owner directly.
This means you need to send the data to the merchant/store owner which the merchant needs to process and send the details to the customer. Alternatively, you can create a template and send the details directly to the customer on behalf of the Merchant.
You need to respond back to this webhook with a 200 success response.
Documentation: Link
I have a JS front-end that communicates with the back-end via REST API and I need to process credit cards. I do not want to get into the full PCI DSS compliance stuff and I don't need to since I am using 3rd party provider(Stripe, Braintree..) that provide tokenization.
But the issue I have is that I do not want the JS front-end to handle the tokenization of the CC details but I want the front-end to send the CC data to the back-end and the back-end will then use the payment gateway API to tokenize the CC data and store it instead of the real CC data.
Since the CC data enters the back-end is is considered processing of the CC data(not storage) which means I have to handle PCI compliance in a way.
So I am wondering if there is some easy way to avoid doing some over-complicated code/infrastructure changes in order to be compliant?
If you don't want to have to qualify for SAQ C/D then you cannot send your customer's PAN to your server, period. It has to go to your payment gateway first, and then you can take whatever payload they give you and send it to your server.
Since I am more familiar with their services, I can describe the two ways Braintree handles this:
1) Drop-in UI - With this method, you'll create a div on your payment page and add a little javascript in your frontend code that converts the node into a payment form. Once they fill out the payment form, the information will sent directly to Braintree, and they will return a payment nonce to you that you can safely send to your server without any PCI concerns.
2) Hosted Fields - The options to style the Drop-in UI are a bit limited, so if you need the ability to add custom fields that you have full control to style and place on your page as you want, then you are looking for hosted fields. It basically creates a series of iframes on your page that you can style like regular HTML inputs, and then when your customer fills them out and clicks "submit," the data is once again submitted to Braintree first, and you get a payment nonce back that you can send to your backend API and do whatever you'd like.
Just to make sure I've been clear though - there is currently no way to send plaintext credit card information to your server without having to fulfill the more rigorous PCI SAQ levels.
I have an application that requests Credit Card information to do a payment to a third party company.
My application captures the CC, CVV, Expiration Date, etc. and then passes that information to their API that charges the customer.
I've been reading about PCI Compliance but based on the following image, I am not quite sure what level of compliance I would need to meet.
Lastly, I would like to figure out what would be the best options for me in case I have a new purchase from the same client. Since I am not charging the customer but the third party does, how would be the best way to store the payment information so user doesn't need to enter his information every single time they want to use my service? What would be the implications of storing payment information on my servers from a PCI compliance point of view? Is there a way where I don't need to store the payment information for the user but I can pass their information (if they are a returning customer) to 3rd party API and still being PCI Compliance?
Since you're building a web application (even embedded into Facebook messenger), if you're building out the form that collects card data, you're going to either fall under "Shopping Cart - Payment Page Direct Post" (which is A-EP) or "Shopping Cart - Payment Page Not Outsourced" (which is D-Merchant). You really want to be under A-EP if you can, but you may not be able to.
The difference between the two is whether or not the card data crosses through your servers. With "Direct Post", the web page itself sends the data (usually via HTTP POST) to the payment API, and you have no way to capture it. With "Not Outsourced", the data comes back to your server, which then calls the payment API and passes it along. In that case, you're going to have to go through the entire D-Merchant questionnaire (by far the longest, other than D-Service Provider), and probably have a special environment set up to prevent anything from trying to read the card data as it transits your server.
There's really no part of the card data that is worth storing to try and identify a repeat purchaser, because you won't have the payment data to actually complete a payment. Instead, you should see if your payment provider provides any type of "token", which can be used to identify that payment data later. If so, you can associate that token with the customer (however you identify a customer) and reuse it when they return.
Further reading: https://www.pcisecuritystandards.org/documents/SAQ_InstrGuidelines_v3-1.pdf
Shopify receives and stores information received from the gateway after a payment is made. It can be viewed in the orders page right at the bottom under Order History section. The words "customer successfully paid..." is a hyperlink. That information contains the authcode apart from some other credit card information. I just want the authcode. The webhook does not send this information in the xml data. Can you retrieve this through the API or is this not allowed? Thanks
Any gateway-specific info is provided through the receipt parameter on the Transactions API. If the token you're looking for isn't there, it's not available.
Thanks for your assistance. Apparently Shopify won't provide that information due to PCI compliance reasons. The payment provider that does the credit card processing will only send one response to Shopify and I was hoping I could get them to send me a response as well but that was wishful thinking on my part. The finance team will just have to log into Shopify and see that information if they need it.