i have a Custom Cart Page which i have built its pretty standard, what i am trying to do is send all the ids of the items in the cart when the user clicks checkout so the user flow is as follows:
1) User Click Checkout
2) Packages added to table one row each item with waiting payment status.
3) User goes to paypal and pays
4) Paypal Ipn picks up payment and order ids via custom field and updates payment status of orders.
So essentially the paypal pay will be a single total payment as opposed to displaying each item. Is it possible to send all item ids via one custom field or do i have to implement a cart style paypal feature which i don't really want to?
I don't see any reason why you can't put a series of Id values in the custom field, perhaps comma separated, but it is only 255 characters long. You would have to parse the field in your IPN handler to separate out the id values again.
But I would suggest using PayPal's cart handling instead, there are no problems with how many items you have to process and also the customer sees a proper list of the items they have bought when they go through the PayPal payment process. More robust and friendlier to the user.
You may find PayPal's Third Party Shopping Cart documentation useful
Related
I am having a problem on an e-comm site i am trying to build where it's possible for a user to add additional cart items when checking out with the SecurePay payment gateway.
When the user clicks 'pay now' button, they are redirected off site to the SecurePay payment page where they enter their credit card information. It's here where its possible for the user to open another page and add/remove cart items after the payment information has already been sent to the payment gateway without me being able to detect it. The shopping cart is a database shopping cart with a cookie as a unique identifier to remember the user.
The problem is that there is no input fields to for any product data in the SecurePay form that's sent to the payment gateway, you can only specify limited information about the order, ie, the total $ amount of the order including shipping(can't even send shipping total separately), a reference number(invoice number) and the currency type(AUD), surcharge percentage etc. So i have to process everything based on the the users shopping cart after the order is successful and they are redirect back to my site. If the user add/removes cart items while they are paying offsite, it is then reflected when i generate the invoice and do the stock take on the order completion page.
Im just not sure how to combat this.
My possible scenario:
I lock the cart when the user hits the checkout page, then unlock it if they hit any other page than the checkout page. Though then there is no possibility of any up selling without taking the user completely out of the checkout process and i'm also worried about any possible scenarios where if the user returns to the site their cart may still be locked. Plus maybe it seems a little messy/hackish of a solution?
I did test a couple random e-comm sites, and it was also possible to add additional cart items from another page during the 'pay now' stage of the checkout process without it detecting the additional cart items unless you actually manually refresh the page. Though i did not verify by actually paying for the items, but i can't see how it would be any different to my problem.
Does anyone have any suggestions?
I initially thought this kind of behaviour was a bug until I learned about upselling. So my solution to this (if I ever needed one), is to make sure every checkout process is a new order, and not a update. And add a hook, to let the user know about the new order, and give an option to discard (clear out) items currently in the cart.
If you can send a reference number, why not use that to generate the order? Whenever the user goes to pay, create an order with the items in their basket and send that number to SecurePay. When the payment is complete mark that order as paid for. If they change the contents of the basket then the old reference number will still refer to the products originally in the basket and if they go to check out again a new order will be created with the correct items in it.
There could be an option - that when the user is redirected back to your site - that secure pay could pass back some information including the amount charged. Then you could check and confirm that figure against whatever is in the cart.
Or - I'm looking at the secure pay developers page and they have two different methods where the customer would never leave your website.
https://www.securepay.com.au/developers/products-and-services/accepting-e-commerce-payments/
Are you in Australia - if yes you could also look at Stripe, it might be easier https://stripe.com/au/pricing
I have set up a small webshop using PayPal as the payment platform. I am in the process of adding a coupon system, but I recently got stuck.
I have a table containing the different coupons as well as a field for each coupon, containing the amount of uses that particular coupon has left.
Now, here comes the tricky part: I am trying to make a system that prevents people from using the same coupon code multiple times, by checking out at the same time. One solution to this, would be to remove 1 use from that coupon before sending them through to paypal.
So here is the actual question: If I subtract 1 use from the coupon before sending the buyer to PayPal, how do I add that use back to the coupon, if the buyer decides to not complete the transaction and just closes the payment window?
you can have a look at PAYMENTSTATUS of GetTransationDetails()
if transaction failure occures you can add the coupon back
I wrote my own shopping cart [in PHP] a couple of years ago that uses PayPal's Classic API "Payments Standard" -- specifically the "upload" command to send the contents of the shopping cart to PayPal. Now I want to add the option to pay for an item with installments and I want that to integrate with the shopping cart process.
In other words, I want the customer to be able to put Item A into the cart and select a single payment option, and then also put Item B in the same cart but select an installments option for that item. Then, when they hit the "Check Out With PayPal" button, I want the Item A and Item B to be processed in the same transaction. My cart also has a feature that allows the customer to enter a coupon code.
I have spent hours running in circles though the PayPal API documentation and I can't find a solution that seems to cover everything that I need:
No monthly payment (I'm too small to absorb monthly payments, so it must be a fee-per-transaction service).
Ability to process single payment items AND installment items from the same cart.
Ability to accept a discount/coupon and apply it to the transaction at the PayPal side.
All collection of payer's shipping address, payment information, etc, done at the PayPal side.
Determine if sales tax is required at the PayPal side.
Provide an IPN type response.
I'd rather not install code on the server [that needs to be maintained or reinstalled if I switch hosts].
Can anyone point me to a solution that could cover all of this?
I was looking at the Adaptive Payments solution but it looks like it I would have to determine whether to charge sales tax (and perhaps have to collect the payer's shipping address info, which I want to avoid). I like everything else about Adaptive Payments. Does anyone know if it will be as "nice" about handling the payer's information, as "Payments Standard" does?
I have a custom store where I'm selling a single product (as a gift), I need to be able to store the recipients address (different from paypal users), a message for the gift and the name they want their gift to be from (if any).
I'd really like to capture the data on this page:
http://sendvalentinesflowers.co.uk/responsive-buy-rose.html
It appears that the standard buttons don't allow this much data to be passed/stored along side a transaction. I'm just wondering how this HAS to be done with IPN? I'm looking for the simplest way to do it.
I would save all of the information in your local database as "pending" prior to sending the user over to PayPal for payment. You can include the invoice parameter in your PayPal code and set the value to the record ID of your local record.
This invoice value will be returned in IPN so you can pull the data back out and process it as necessary, and also update the existing record's payment status according to the current IPN.
I'm currently implementing Paypal Express Checkout within a Zend Framework Application, I wrote my own cart model which consist of two simple class Cart & CartItem, and they are able to se quantity, get total price, etc.
I'm not much aware on payment system, and I only use Paypal (it's my first time), but I though since I'm not able to control what's happing there (at Paypal) it is a good idea to "lock" the Cart at the beginning of the process (when redirecting to Paypal) to avoid inconsistencies over the current Order processed by paypal and the actual cart on the website.
It can happen for example if the user open a new tab and try to add products while he is a payment process with paypal.
If your cart is locked the use is not able to add or remove anything from its cart until he finished to process the payment thorough paypal or cancel its order.
My question is do you think it is a good approach?
Edit: The reason I don't store anything in the database but only the shopping cart in session is all order are stored with Paypal, so I don't want to store it twice, it is a really really simple system.
I've done it a different way.
When the user browses the site, the cart is stored using a session, a cookie or whatever.
Once he clicks the "pay" button, the content of the cart goes to a orders datable table with a unique ID.
You delete the session or the cookie to prevent him to add new stuff to the order.
You use the unique ID to give it to paypal. Once the payment is done, Paypal comes back to you with IPN, and gives you back the unique ID. From that you know it's paid and can put a boolean or something in your orders table.
Sometimes the user won't pay, and you'll have some never paid orders. You should have a cron that check orders older than one day and remove them from the table.
I think your approach is fine. But make sure you inform the users why they can't add items to cart and offer an easy option to unlock the cart.
Use case:
fill cart
start payment
ah, I forgot the socks
close payment tab
shop opened in other tab
add socks
"you can't add, it's locked"
I can't return to payment to cancel it and can't add anything to cart => i leave