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.
Related
I've ran into a problem. Basically, I have a website that users can hire someone to tutor them. Each tutor has a small profile with a video, bio and rating. The user fills out a form with information such as their name, email and the most important one which is the date and timeslot (Dropdown) they want. When they fill out this information they can then click "Buy Now" which is a PayPal button I've setup. There are no variables here, each time slot is the same price all round.
The problem I'm having is I don't know how to collect the user information when the PayPal button is clicked. Can I pass this timeslot to PayPal who then return it to me? I can set up simple form that will send this information to me in an email, however I don't know how I can trigger that PHP script when the PayPal buy now button is pressed.
Any help? I've been Googling for a while, I can't seem to find anything! Maybe I'm wording it wrong. Anyway, hope you guys can assist.
I would save all of the info in your database prior to sending the user over to PayPal. That way you can include the invoice number (or record ID) in the invoice parameter in payment requests.
If you're working with Payments Standard the parameter is called invoice. If you're working with the Express Checkout API it's called INVNUM.
Hi you can use Ajax in this situation. The ajax will prevent the redirect of the form to paypal for awhile but executes another process in which you will save and capture the information of the form to your database. After the process the redirection to paypal payment method will continue.
You can view this good tutorial in here.
http://anytch.com/save-html-form-post-to-database-before-redirect-to-paypal/
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!
I'm e-commerce developer and have a problem, at certain part of the purchase my code generate a submit form with the purchase info. And send to payment gateway.
This form is generated on PHP and after its generate he write
document.getElementById('formnid').submit();
I'm having problem because somebody are sending discount value to gateway, and i don't know how.
At certain point my project save a log, after generate this form and submit it. And on my log everything is allright. So i suppous he change the value between my send information and gateway geting the info.
Somebody can give me a light i need discovery how he doing this.
Ty in advance
When the payment confirmation comes back from the gateway you should check that the actual amount paid matches the amount that should have been paid.
Only then has the user paid. It's fine to post prices along with your form but it must always be checked upon completion.
If the pricing / discount information is hidden on the DOM (via hidden inputs, for example), manipulating the DOM using Chrome's "Developer's Toolbar" or Firefox's "Firebug" is trivial, allowing for any end user to make changes to those hidden inputs without reprieve.
Never trust the values that come on the form, the value must be always be set\validated on the server side. From what I gathered you are passing the value as a hidden field on the form, and the user is simply altering that.
Context:
I have to add an online payment system, on a quite old PHP 4 website (Yay !).
As usual, an external payment platform/gateway will be used.
After preparing an order on the website, that payment platform expects to be called with POST data, then displays its online payment page if everything is Ok.
Question:
Would it be a bad practice to autosubmit a form with a bunch of hidden fields, in order to switch to the payment platform?
It seems that I don't have the choice but I would like to know if someone sees a better way for that online payment platform integration.
Current workflow:
... last ordering step: order summary
user clicks on "order" (that button is already part of a form which action is an internal page)
results page (generally: order successfully saved, will be quickly processed, etc.)
The new detailed workflow would be:
... last ordering step: order summary
user clicks on "order" (that button is already part of a form which action is an internal page)
after existing internal processing, redirection to the "autosubmitted form" page
the autosubmit form submits itself (its action being the payment platform URL)
online payment...
result page
NB. I would add some "please click to order" button for users having Javascript disabled.
Thanks for any suggestions / thoughts. Or even telling that there should be no problem with this :)
Autosubmit a form with a bunch of hidden fields, in order to switch to the payment platform is ok. But you should pay much attention to security here, because intuder can modify those hidden fields.
I am in the process of writing the final stages of a checkout module using the FirstData Global Gateway API for a client. All the form views for data entry have been created and the controllers are successfully communicating test data with the FirstData webservice.
I am looking for thoughts on best practices on how to structure the user experience for checkout after the 'process order' button is clicked.
I am planning on using javascript to disable the process button after it is clicked and have the information passed to the Web Service during this delay. What are some methods you may have used in the past to create this delay while informing the user that the payment call is being made. What are some methods you may have used in the past to best operate the callback function that notifies if the transaction has been approved or declined? Has anyone found processing all this information in the same script using PHP_SELF for the action, or is it generally better to place this logic elsewhere?
Just some general inquires to help guide the process through a little trial and error. Maybe the response will help collect some pretty good thoughts for everyone's use.
What are some methods you may have
used in the past to create this delay
while informing the user that the
payment call is being made?
You don't want to delay the process any as processing the payment will incur enough overhead for natural delay to occur by itself. Your goal at this point to prevent duplicate submissions and let the user know something is happening while they wait. Disabling the submit button is a good idea. Also, creating a unique key for that checkout process that also needs to be submitted with the order is a good idea. When they submit their payment you check for that key and make sure it is there (usually it is in a session variable). If it is delete it and then process the transaction, if they submit the form again it will then be able to be flagged as a duplicate transaction.
What are some methods you may have
used in the past to best operate the
callback function that notifies if the
transaction has been approved or
declined?
The payment gateway is going to return an approved, declined, or error value. Nothing fancy so there's really no fancy handling required. Approved transaction should have all relevant order and database information actions performed and then the user should be taken to a thank you/receipt page. Errors and declines can be handled in a similar ways with the user being presented with the checkout page again. If the card is declined let the user know politely that their bank declined the transaction and invite them to use a different credit card. If there is a processing error you can either ask them to try again or direct them to contact you by telephone to place their order.
Has anyone found processing all this
information in the same script using
PHP_SELF for the action, or is it
generally better to place this logic
elsewhere?
Tomato, tomáto. It all depends on your programming style. Having the payment process on the same page as the form is fine. I've done it. All that matters is that the payment is handled properly and the user sees what they need to see. What happens in the background doesn't matter to them.