I am in the midst of trying to find an e-commerce solution for my employer, and it is necessary that we go with a hosted payment page to minimize our PCI compliance woes. After researching several companies' solutions, it seems that they all expect you to submit the total price of the transaction to them via a hidden field or GET variables in order to generate the payment form. This seems like a sizable concern for the merchant, since a user with Firebug (or eyes, in the case of GET variables) could easily modify the transaction total, get a new hosted payment form, and continue with the checkout, thus giving themselves whatever discount they desire.
Has anyone set up a hosted payment page before and dealt with this issue? Any suggestions for a better way to do things?
There usually is a hash submitted with those forms that are generated with secret values that the user won't know (e.g. password, transaction key, etc). So if they tamper with the amount, which is also used in calculating the hash's value, then the payment gateway will reject the transaction. The user cannot bypass this by changing the hash because they do not have all of the information required to calculate it.
So using these hosted forms are safe from abuse. If they weren't they wouldn't be viable products and the gateways couldn't offer them for use.
Related
We ship using FEDEX and UPS, and we never found a need to post the tracking number to the payment record, however, recently a customer did a charge-back and the claim was that the order was not shipped even though it was. The tracking number was not entered into paypal, but we do have a tracking number for this order. Do we need to manually enter every tracking number into Paypal, or do we have a chance to enter it after a chargeback attempt has been made?
PayPal's standard API does not provide a field for tracking numbers in their order details, so there is no way to automatically send PayPal this information for all orders.
Their API supports disputes, so it could be possible, however it looks like it could be very messy. The workflow would look like this:
Use PayPal's Customer Disputes API to GET all disputes with a dispute_state of REQUIRED_ACTION and reason of MERCHANDISE_OR_SERVICE_NOT_RECEIVED. Save the Order ID
Cross reference the Order ID with your order management software's API to get a tracking number. If the tracking number exists,
Use PayPal's Customer Disputes API to escalate the dispute to a claim and save the returned claim API endpoint.
The documentation gets a little fuzzy here and may require some contact ith PayPal's support team, but it looks like you should be able to POST evidence to the claim with PROOF_OF_FULFILLMENT, which includes tracking_number and carrier_name.
Unless you are processing a high volume of these missing order claims it probably won't make sense to go through all this legwork. If it truly is taking a lot of time and energy for you or your staff to handle this specific type of PayPal dispute then maybe it would be worthwhile. I might also suggest in this case to start toggling the "signature required" settings for your shipping partners.
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
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
I have a situation where I am to bill the site users monthly. But the invoice amount that is raised depends on the the leads that our site generates for his business. For example if the user gets 5 leads from my site and I charge him $10 per lead, at the end of month he will be charged $50. similarly leads might vary each month so will the amount.
Now I cant store his cc/ paypal credentials on my site for security reasons nor can I pre bill him or ask him to take credits and then use it. Please let me know the way to handle this situation. How can I handle this using paypal?
There are a few different ways to handle this, but I would recommend Preapproved Payments, which are part of the Adaptive Payments API.
With this method your users would create a profile with you (using the Preapproval API) when they first create their account on your site. That will give you a preapproval key that you can store with your user account. Then in the future when you need to bill them you can use the Pay API with the preapproval key to process funds immediately without further approval.
If you're working with PHP my class library for PayPal will make these calls very simple for you. You would just use the Preapproval.php template to setup the profiles for people, and then use PayWithOptions.php to process payments using the preapproval key(s) accordingly.
If you end up using it and need more help you can contact me directly for support.