I have a question that has been bugging me for quite a while now. I am working on a project that has a form tied to a payment gateway. This form is validated and once valid after the user clicks 'Sign Up', the credit card number is automatically charged (without review).
I am trying to add an intermediate step that is pretty much a summary of the amount that is going to be charged and the information that is going to be used for account creation. I am debating between the two approaches:
1) Post data is posted to an additional page before the account is created (and credit card is charged), from this page if all information is correct (in the users eyes), users click Sign Up and then the account is finally created - this would probably require re-posting the variables or creating session variables...
2) Use JavaScript to hide the form 'on submit', and show the initially hidden, review container, using javascript, which will set html fields of the hidden review screen before showing it, from here when a user confirms all information is correct, the account is created / credit card is charged, and we did it without session / reposting of variables.
However, I noticed a lot of websites tend to use approach number 1 from the above. I was wondering why is this, and is approach number 2 a decent way to tackle this problem?
I appreciate any advice, many thanks in advance!
Related
OK. I have my connection to my database allowing content to be posted to my website from users.
I'm missing a key function that will allow me to charge users before they post a posting to my website.
I have been searching for a course or solution example for weeks now and have been unsuccessful. Can anyone help me or lead me in the right direction?
Here is an example:
dummydata form image example
This will work to take you to a payment portal but will not submit my form data to database after payment is complete. If I change action to action="" the data will be sent to my database but no payment will be required.
Thank you in advance!
There are three essential steps:
collect and verify payment
collect content to be posted/displayed
enable post for display on website
Steps (1) and (2), the collection steps, can happen in either order. And probably sequentially, one right after the other. But importantly, they CANNOT happen simultaneously. They are separate processes that occur one after the other.
I am implementing PayPal HTML buttons on my website, and I want to know what would be the best practice for registering customers to use my website. Should I have users fill out information before they pay and validate their accounts once a payment is made? Or should I have them create an account after a payment is verified? Also, at what stage should I input any associated data from the customers into my database? Thank you for any tips/suggestions!
Edit: My website is an online software website where users will pay a monthly fee to have log in and software access.
To me, payment should always be the last action of the user cause if anything else goes wrong, you don't want to have to undo the payment. So let the user navigate your website anonymously if he wants. Then, when he wants to buy something, ask him to log (if he already has an account) or register (if he does not have the account), and then he can process the payment on paypal once he is authenticated.
You will send his information to the database when he submits his account registration. If his submissions fails for some reason (missing field or whatever), he will have to do again until it works.
Not sure that answers your question. Of course, that seems the most logical way to me, but there might be some cases where you want to do things differently (which I do not see right now)
Imagine a site like istockphoto or envato where the user can only purchase digital credits...
How would one implement this in the cleanest, easiest way using paypal's API's? The docs there are a bit confusing to navigate...
Aside from that general "best-practices" question, my guess was to start with the Integration Wizard at https://devtools-paypal.com/integrationwizard/ and select "Express Checkout - Digital goods"
After setting up some test accounts on the sandbox, I've kinda sorta got it working- but I'm confused how I track dynamic data across the session.
I.e. where would I securely store the "number of credits" and "userid" values so that it gets added to this user (who may not have an email address, nevermind one matching their paypal account) upon successful payment. Is a database/callback system necessary?
Assuming so for the time being, my guess is to maybe store the data in a database where the primary key is the TOKEN received at SetExpressCheckoutDG(), and prepopulated fields are the data I want to keep... and then the final confirm.php page will check the database at that token and implement that data... but something just seems strange about that, i.e. relying on a callback (could be timeouts, etc.) and I'm not sure if it's really the most secure way of doing it.
If using examples, please stick with PHP (not curl or other langs). Thanks!
You could just bounce this along with your calls. I'll use NVP for my examples
You set your digital goods in SetExpressCheckout. Inside, you pass how many credits the user is buying and set the PAYMENTREQUEST_0_CUSTOM with their user ID.
In GetExpressCheckoutDetails that data would be passed back to you so you could store it in some fashion (you would get their items and quantity, plus the user ID). Then, you finish with DoExpressCheckoutPayment.
If that still doesn't help let me know.
I see many examples of how to display transaction information to a user with PDT. I cannot find a way to associate a Paypal payment with a specified ID so that when the transaction is completed, I can update that ID in the database as paid.
How am I supposed to get an ID that I specify back from Paypal so I know what the payment is for? I cannot use the email address or name or anything else. It must be an ID that I specify.
I see some people using item_number, but I am using a Paypal encrypted button so I cannot add on form variables to post to Paypal when the user clicks the pay now button.
I see this on websites all the time, so I know there must be some way to do this. I just can't find it anywhere...
Thank you
Most often people encrypt their own buttons and use either the custom field which gets sent pack to you, or the item number field. Look into how to encrypt your own buttons with PHP.
PayPal offers a sample in their SDK which can be found here.
I stumbled upon this excellent piece that succinctly lays out how to make dynamic encrypted paypal buttons. It is just what I needed. Thanks for pointing me in the right direction!
http://www.stellarwebsolutions.com/en/articles/paypal_button_encryption_php.php
One of the web applications I recently developed works like this:
User picks a subscription level
User enters various custom/personal data on the site as well as picking out certain options
User confirms their data
The system stores this data in an array with a flag set specifying that the data is incomplete
The user is directed to PayPal to pay
PayPal makes an IPN request and we grab the row ID containing their information and complete the rest of the fields, effectively completing the process.
Now, obviously there are a few problems with this approach.
1. These rows are created whenever a user visits the form and can quickly add up
I solved this issue by adding a last_touched column which is a timestamp, and I routinely delete records older than 48 hours (more than enough time to complete a PayPal transaction).
2. Because of the above, it's possible that a user could checkout successfully with PayPal and there is no row in the database
I transmit the essential information such as the ID of the subscription package with the PayPal custom field, and if the row doesn't exist when I'm doing my IPN request, I fill in the blanks using the data supplied to PayPal and from the custom field.
3. The username the user entered could theoretically be taken by the time they checkout
I've solved this by checking to see if the username is taken and if it is, I add a number to it and keep incrementing the number until I get an available username.
I'm not sure if this is the best way to handle the given situations or if there is a better alternative (Not involving PayPal Payments Pro). At which point would the potential issues with a system like this outweigh the cost of PayPal Payments Pro?
Your best bet is to store all account information on your database as if the user created the account before sending them to PayPal.
So store everything including the username before allowing them to proceed to the checkout. This enables you to validate their information and username before they go to PayPal. Then you cache it all for 48 hours just to make sure they don't lose the username while checking out. You could also take advantage of PHP's session support to track the user if they happen to come back the next day to make the purchase. As long as they didn't clear their cookies/cache and your session lifetime hasn't expired the session server-side, they should be able to resume the session right where they left off and go straight to PayPal.
I would still send all vital data to PayPal just in case the user somehow manages to sit on PayPal's payment page for a week and then decides to put in CC info.
You could also use this system to "check" if the user has already started paying. Perhaps ask them to enter an email address first. Associate all data to that email and the user's IP address ($_SERVER['REMOTE_ADDR']). If you don't have session concurrency for a user, but they enter an email address already in the database. Check their IP (and maybe even browser too if you want to be really anal about it) and if it's a match, tell the user "looks like you started checking out before and never finished. want to continue?" and let them pick up where they left off. Obviously don't store any sensitive information this way, and only cache it in the temp table for paypal stuff so it only lasts for 2 days at best.
This way the user can click "Yes" and they don't have to choose their subscription again and go through all that picking/deciding a second time. If the user says "No, I'd like to start over" then just delete the row in the temp table and make a new one for them.