I'm currently programming a small basket app and I was wondering what was the variable that would be used to differentiate between subcriptions for one user.
Let say my user has 4 subscriptions, and it is now the time to receive its recurring payment. I receive the payment message from Paypal, parse it and do my DB update. How do I know which recurring I need to process?
From what I read, its probably the subscr_id=I-HPDM8GP... that I need to check but I'm not sure?
Thanks
This is a pretty broad question so I'm going to have to make a couple of assumptions...
1) You're using standard subscription buttons..??
2) You have a users table in your database already, and it relates to an orders/invoices table in your database by customer ID..??
If those assumptions are accurate, then what I would recommend is that you include the order ID from your system in the "invoice" parameter with the subscription button code.
If you're not already using it then it would be wise to setup an IPN solution to process subscription payments, and within the IPN data you would get the same order ID back in that "invoice" parameter, so within that solution you could update your system accordingly using that order ID which then relates back to your customer IDs in your own system.
With all of this data included and related correctly in your system you could easily pull reports for different users that include all of their subscriptions and payment history.
Related
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 implementing PayPal payments pro for a client at the moment, and therefore I am configuring the IPN service to confirm the purchase on the clients server. What I can't work out is which field should be used to "carry" the id of the order to be passed back to the IPN handler?
Some say the invoice field, and some say the custom field...
What is the best practice? (if there is one)
I know there are some similar questions out there, but I am looking for a definitive best practice answer.
This is exactly what the invoice field is for. That is best practice.
With at least some of their products PayPal also applies duplicate-payment testing based on invoice but not on custom. This is usually a good reason to put your unique order identifier in the invoice field (you don't want a user to pay for the same purchase twice) but if, for some reason, this doesn't mesh with how you handle order IDs then you could put your order ID in the unmanaged (by paypal) custom field.
Best practice is Invoice field, just be aware with the possibility of Invoice locking - prevents someone from paying for the same invoice twice.
For example two people checkout at the same time, you pass Paypal the next invoice id - so both users are attempting to pay for the same invoice. After one person completes the transaction the other one will get duplicate invoice error.
This is more of a question regarding flow than code.
I'm currently working on a booking website for a holiday home. I've implemented a booking system which currently takes full payment at the time of booking. This uses PayPal REST API. It works fine no problems code-wise.
However my client would like the system to take a deposit when booking (20%) of the total. Then take the remaining amount later on (through the site). This seems strange to me and I've never used a website which does this so I'm not sure what the flow should be.
The only way I can think of achieving this is that the user has to come to the website at some point in the future to pay the remaining amount. I could send them email reminders but it seems a bit awkward to do that.
Has anyone done anything like this in the past?
In order to take the money later, you need to store the credit card data in your system, which is not quite legal unless you are authorized payment service provider (and I'm almost sure you're not).
We have the same case in our reservation system. Generally, you'd allow credit card payment only for deposit, and later final amount is paid via bank transfer or cash, for example, and has to be settled manually by an operator.
Your idea is not bad, however. You could inform the user about the final amount and due date in the booking confirmation email and later on send them reminders.
You can utilize reference transactions to handle this without storing/saving any billing information on your server.
Reference transactions can be used in Express Checkout as well as with Payments Pro.
Basically, the way it'll work is that you can process the original 20% and then you'll save that transaction ID in your database. Once you're ready to process the remaining amount you just make a call to DoReferenceTransaction and supply the original transaction ID along with the new amount to charge. PayPal will then charge this new amount using the billing information that they have saved on their server.
I have looked around SO for this but I can't seem to find anything like it.
On my service, I wish to charge on a per-month basis depending on how many users my clients have.
So this question is split up into two parts.
What I want to know is it possible for a client to use their own paypal account (without entering any CC details) with conjunction with CreateRecurringPaymentsProfile via the NVP, I have looked through the documentation and can not discern anything. So clearly it is not possible to do it via NPV - From what I've seen so far.
i. If I do an Express-Checkout Subscription, I can do 20% change on total amount every 180 days (I DO NOT want to do this) - I want to be able to get the Profile via the IPN and then modify the monthly amount on as-need basis
ii. There was some mention of Referenced Transactions, but the Documentation is very confusing.
So say there is a way to create a recurring payment subscription via a PayPal Account on the PayPal website, next step is to be able to update the Subscription via UpdateRecurringPaymentsProfile NVP command.
While I am happy to pass on CC details (which already works great), I am just wondering if it is indeed possible create a button, which would create a Subscription - once on success an IPN request is sent back with the ProfileID which I can modify the Billing Amount by NVP.
So TL;DR;
The current flow I have
Register on our website
Enter CC Details
Backend submits the data to PayPal and if passed - continues on.
On any Account modifications, update Profile Monthly Amount Automatically.
The flow I want
Register on website
Click on an Authorize Button Redirected to PayPal
Login to their PayPal Account Create Recurring Profile.
On any Account modifications, update that Profile Monthly Amount Automatically.
edit to add - this is all working now, had to contact and harass PayPal directly for a lonngg time.
I'm a little confused because it sounds like you answered your own question, but then said that's not what you want..??
Express Checkout does exactly what you outlined at the end of your post, and it triggers an IPN just like any other PayPal transaction. You are indeed limited on how much you can adjust the amounts of profiles created with EC, though, just like you mentioned with the 20% every 180 days. If you create profiles with Payments Pro (DoDirectPayment or PayFlow) then you're not limited and you can adjust the amounts however much you need to whenever you need to.
Reference Transactions and Preapprovals may be something to look into as well. I actually wrote an article about what they are and how they differ from each other awhile back that you might be interested in.
I understand how IPN works, and the basic idea of the sending of information, verifying etc. But for the life of me I cannot get it to work!!
This is what I'm trying to do...
A user selects a certain part of a product to purchase, once they click it, they are linked to a paypal button which I've added 2 text fields to. First is there User ID and the second the name of their selected part - both of which the value is added in automatically. That all works fine.
They then press Buy Now and fill out their card details and it is purchased and redirected to a success page.
However, I want it so it updates their profile in my database to show they have purchased that product.
I understand that using PayPal's IPN I can send information to a page on my site to check it, and if the payment is complete then take whatever action needed.
I have tried the scripts from the PayPal site itself and I get no response at all. Can someone give me a really, REALLY simple method of achieving what I'm after? Because every tutorial out there is overly complicated or doesn't work, and the examples don't help me in the slightest and they talk to you as if you should know how it's done already.
I've even read the whole PDF and still I'm clueless about how to get this working. Any help?
This really depends on how you have your users stored in a database.
How are they identified, do they have a username?
Are you saving transactions to a database before you submit the information to PayPal?
Basically, you would want to look at the IPN Variables and see what you could use to associate the data with your databases when the IPN message is received by your script.
Lets say you have the following Databases:
Users: ID, email, etc.. etc..
Transactions: ID, emailofUser, invoiceID, Success/Fail(bool)
You want to store information to the database before you send the data to PayPal - "Hey, this guy was sent to PayPal to purchase this".
Then, IPN comes in when you want to ensure that the item was actually purchased. You don't want to offer someone the benefits of purchasing an item just for being sent to PayPal, you want to make sure they actually completed payment. Going off of the IPN variables, you could easily use the 'invoice' variable (as long as you define it appropriately when you send the data to PayPal).
So lets say you send a buyer to PayPal, he completes checkout, and your script gets an IPN message. You'll want to do something like the following:
Verify the IPN
Check what invoice this is for
mysql_query("SELECT * FROM Transactions WHERE invoiceID=$_POST['invoice']");
See if the transaction is successful or not.
if ($_POST['payment_status'] == 'completed')
{
//update whatever information you need to
}
else
{
//something else happened with this transaction, put a flag on it for review by
//an admin
}
You should check out the links below which describe a little more about managing your orders
Order Management Automation
Order Management Guide