My shopping cart for a ski lessons website works as follows:
A customer selects dates that they want ski lessons on. Some dates have different prices, for example school holidays and weekends. They submit the selected dates, and the event and its details is provisionally logged in an SQL table with a random transaction ID.
The shopping cart has also added up the cost of all the selected dates and creates a Paypal Advanced Buy Now Button with the price.
The customer pays for their selected ski lessons Paypal which sends an IPN back to my IPN listener for verification and to confirm the order.
There's a problem with this though, my IPN script only knows how to verify for a static price, and since every order will have a difference price depending on selection, I need to relate the received IPN to the specific order that was originally placed.
After some poking around I wondered if it is possible to manipulate the txn_id to be the same as the random transaction ID set in the first step above. That way when the IPN report comes back the script will know know exactly which event it is referring to and I can compare the details of that event (e.g. the amount paid compared to the amount calculated_ to the variables returned in the IPN report.
Is it possible to manipulate the txn_id, or otherwise send a different identifier with the Paypal button so that I can identify the payment?
It's possible to send the identifier in the "invoice" field, which PayPal will send back in the IPN.
Related
What are the parameters which PAYPAL and 2Checkout sends for IPN in case for buy without subscription, subscription first payment, subscription not first payment and refund.
I need understand the workflow so I can implement correct. I already checked the documentation and I already build the form for payment with/without subscription.
The full parameter list is located https://www.2checkout.com/documentation/notifications/order-created there for a non-recurring sale, use the sidebar nav on the left to find the recurring INS messages. Each INS link has a description as to when the event is triggered:
e.g. Order creation is a new order placed online by a buyer. You may want to automate inventory management, fulfillment or setup of login credentials based on this message.
Recurring order creation is a special case of order creation; if any item ordered is recurring, the recurring parameter will be set to 1, otherwise, it will be set to 0.
Please note the initial installment billed often differs in price from the installments due to startup fees.
Order Created is an invoice level message; it will be sent once for each new sale and will contain information about all items ordered.
I'm using PayPal to take subscription payments for access to a website service.
I'm using PayPal's IPN to manage the payments and user accounts.
I'm sending a custom random key to PayPal, unique to each user, when the subscription is first instantiated so the same key is sent back with every IPN. This means I can bind together my users table with my PayPal notifications very positively.
Accordingly I can now generate from my database a list of user_ids and notification details.
So now I need to figure out the best logic to use to calculate each users current payment status and, as a consequence, what to do with their account - whether to continue allowing access, suspend or even delete their user account. This decision will all come down to whether their payments are still coming through or not.
A bunch of interesting an varied data comes through on PayPal's IPN - most looks irrelevant in terms of user account management but a couple of columns look quite useful. Specifically...
Field outstanding_balance appears to contain exactly that - a value to 2dp of money still owing. So far during my testing this figure has only ever been 0.00
Field txn_type shows me any from a selection of different codes: subscr_signup (when the user initially sets up the subscription), subscr_payment (when a payment appears to be successful), subscr_cancel (this seems to appear whether the customer or vendor cancels the subscription), and subscr_eot (end of term - this one crops up shortly after the subscription is cancelled).
My impulse is to search the table for the most recent txn_type="subscr_payment" entry for each user account, and check the date this last notification arrived. If it is date stamped over, say, 28 days ago the account can be suspended... if it's over 56 days the account can be deleted.
Is this a good idea? Or is there better logic I can employ?
I've done this. Quite simple:
Don't grant access until you receive the first payment. You can get the intial signup and payment in either order.
PayPal will notify you if they cancel their subscription or it expires. When you get either of those, deny access as from the effective date.
If the most recent payment status on an account is 'reverse', suspend access until you either get 'cancel reverse' or the situation is sorted out in some other way.
Don't count the days. PayPal counts the days. All you can get from repeating that yourself is a disagreement, and guess who's right? PayPal. And guess who isn't wrong? The customer. You don't want to penalise the customer because PayPal got behind or had a different idea of 28 days from yours. You've handed responsibility for collections and renewals to PayPal: let them do it.
Beware of building policy into this. It should just be a mechanism, and it should be manually overridable. For example, the actual evaluation of whether this user has access to this product now mustn't be a computation over their payment history. Just a simple lookup of another table, which your IPN code can modify, but so can humans. For example: there is a dispute. You lost. You might well as a matter of business want to keep the customer alive for a grace period anyway. Alternatively you might in extremis want to fire the customer immediately, e.g. for usage violations.
You can ignore the balance field. The only important thing is the txn_type.
I am working on a website to sell some advertisement concept online, where user can get the access of more options after opting a monthly subscription paying through recurring Paypal.
I have already implemented the recurring paypal functionality successfully except one thing. Like One can subscribe for the plan and monthly payments are deducted from the concerned account.
But I have no idea how to update my database after the first payment from the recurring paypal.
eg, a customer comes to the site, choose his options, went to paypal recurring part and made the transaction. Now I have one page , where the paypal returns the control, which is given on the return url. Now the problem is, in this page when I am updating the database, the paymanet status is pending.
Then after a while when the IPN response comes to the application, I wont able to update the earlier entry in my database, as I am not sure how to match these two entries, I mean upon which field the update query should be coded.
There's no point in updating the database at all until you get the money. When you get the money, the transaction contains everything you need to create or update the subscription.
Hey guys was hoping you could help me out.
I am integrating paypal (for the first time) in a website using PHP. From what I have read, there are two methods for confirming a successful transaction, PDT and IPN.
Now the thing is, the item's being sold can have a limited stock. So if suppose a person reserves an item and is taken to the PAYPAL site for final payment, I have to stop all other people from making a purchase since the last piece of the item will be "reserved".
But suppose the person (who has reserved the final piece of the item) goes to the paypal page, and then simply closes it. Will this result in a "fail" ipn coming to me (so I should un-reserve the item so others can buy)?
If so, how long will it take for the failed IPN to come?
If not, how exactly should I handle this.
And is there any scenario where an IPN does not come?
You could use the Express Checkout API.
With EC, the payment is a two step process. In the first step, you make an API call (SetExpressCheckout) where you set up the transaction, and redirect the buyer to PayPal. Once there, the buyer authorizes the payment, and returns to your site.
At this point no money has changed hands. You need to make a second API call in order to capture the funds (DoExpressCheckout).
You can hold the item for a specific period, and if the buyer abandons the transaction, or is very slow to approve the payment, you can release the item back to the public. If he eventually approves it, and does come back to your site, you would simply skip the second step, and inform the user that his transaction timed out. No money changes hands, no items are double sold.
i have included the payment system in my site using paypal.
in paypal, i have choose the payment message service as IPN.
Now i have some question about the flow my site, i don't how to handle it.
1) Now If the user name called "A" had paid for some service and at the same time user name called "B" is also making payment, How about I came to know that which user had paid for the service? [ means what should i include in my payment flow to know about the user? should i add the user id with my item name and then get that id from that item name in IPN message url]
2) What time is taken by IPN message, bcz last time when i was checking my payment module then i don't know when my message was sent by paypal, but it was certainly taken time say more 3 - 5 min, now what should i do to get the payment status immediately bcz in my site i want that, as soon as user had paid then that service should start immediately.
EDIT: Can i include any custom data with my payment. Bcz in IPN message sent by paypal, their is one filed called "custom" sent by the paypal so to add that if i have to include that file in my payment form.
1.)
there are custom HTML transaction variables that can be set for things like this and you will have to name the input tag accordingly. There would be two input elements for each custom field that you want to save. One for the field name and one for the field value.
These tags are on0, on1, or on2 for the custom field names and os0, os1, and os2 for the custom field values.
I would send on0 with a value of "UserID" and os0 the actual ID.
These values will be represented in the IPN as follows:
os0 is represented as option_selection1
on0 is represented as option_name1
Here's the info on PayPal's Parameters
2.) They are almost always within 5 minutes, but I have heard that from time to time there can be periods where this might be significantly more. You can always create a PDT success page that digests the same info that would be in the IPN message. This would be your return page from the paypal site and all your data would be included in the request. Just make sure you keep track of you still use the IPN in case the transaction succeeds but the user never makes it back to your site. I like using both methods so you can customize the welcome back to your site for the user based on their transaction. And if you doing that and have all the info you need, might as well process the order as well.