views:

38

answers:

3

Note: Our site is built in PHP and uses MySQL databases. I already manage another site with shopping cart in its entirety using Authorize.net so please dont respond with suggestions to use another provider. A new product/service we are releasing is classified as "High Risk" to the merchant providers and they want to charge us out the a**. In response, I figured setting up a Website Payments Standard account on Paypal.com was the best alternative for the following reasons:

1) no monthly charges, only pay for what is used

2) trust brand and people are comfortable with Paypal

The rates are quite a bit higher than we are used to but any High Risk Merchant account is so that is irrelevant. The issue I am running into is this:

1) throughout the registration process on our site, we collect quite a bit of user information and pass it from page to page using SESSION variables. When you use Website Payments Standard, you are forced to pass the consumer off to a Paypal owned webpage to submit their payment information. Upon successful completion, they are able to direct them back to a 'confirmation' page on our site but it is my understanding there is NO way to keep the old SESSION variables in tact. This is very important to us because the overall concept is to store the SESSION variables ONLY after successful payment has been made.

2) Using Website Payments Standard, I am unable to find a way to send a Pay-Amount variable (everything must be dictated up front, i.e. T-shirt is $2.99). Our site allows the consumer to enrollee multiple persons and have several 'add-ons' for each person so there are literally over 100 end check out amount possibilities. I am not sure if it is possible to override this.

Has ANYBODY had luck using Website Payments Standard on Paypal acknowledging the information above?

+1  A: 

1) Assuming the Session is cookie based, it should still be there when they come back to your site (as long as they havn't closed the browser window in the mean time which is unlikely).

If you really wan't to be sure, store the session in the database in a temp table associated with the order_id you're generating. I belive it's possible that this (order_id) is passed back after the transaction is completed. Read the docs on PDT.

2) I belive this is not the case. Check the docs page 250 onwards.

Pete
A: 

1.)I agree with Pete above in that your probably looking for the PDT functionality. It sounds like your best bet would be do digest the request sent to your return page for the PDT variables and build your session variables then.

2.) You can send any amount you want using the "amount" parameter. Here's the info on PayPal's HTML parameters

jumpdart
@jumpdart - I have had it with PayPal. Their service and support is pathetic. I have been waiting for two weeks for them to evaluate the PHP script we developed for encrypting our payments and their solutions are laughable. Not only do they neglect answering our actual issues but they recommend things which go against their own best practices.
JM4
you are completely correct here. If you ever call for help with the web payment standard they tell you what you want to do is not possible and that you need to pay for the deluxe package API or whatever. I gave up calling for help along time ago. And their documentation organization leaves something to be desired as well. Well good luck with whatever you decide on!!!
jumpdart
A: 

Question 2 should be responded, regarding Question 1, I'd like to add that you can simply use the builtin Session functionality of PHP as usual (whichever Storing mechanism you have in place then, may it be memcached, file (default), mysql database or whatever), and pass the session id to paypal.

When paypal calls back to you, you can access your Session Variables by using session_id($backpassed_sessionid_from_paypal), which simply loads the session data associated with the sessionid you pass into the function, which is probably what you meant.

craftyfirefox