New PayPal System Confusion

[xxkylexx]

Hey Matt,

Just upgraded to 3.4 and am a little confused about the new Paypal system. I want to force paypal subscriptions, so I have that option ticked.

 

The one thing I am confused on is how the system handles multiple billing cycles on various items ordered at the same time now. In the past versions, you created multiple subscriptions for each item.

 

For example, with the current system, a customer orders a hosting package for 8.99 /month as well as a domain for 7.99 /year. After ordering, an invoice is generated, and the Paypal subscription button is displayed at the top of the invoice. The customer creates the subscription which gives the terms of 16.98 for first payment with 8.99 recurring each month. According to this, the domain is being paid for, but will not be part of the recurring payments from there on out.

 

So, what happens when one year passes and the clients domain is up for renewal? This subscription will not pay for it, right? How is this type of situation handled?

 

Thanks,

Kyle

[mrprez]

They will get an invoice for the domain renewal.

 

John

[xxkylexx]

In which they will create the subscription at that time, one year down the road?

[xxkylexx]

Also, I now notice that invoices are generated for users with subscriptions. Isn't this going to present a problem?

 

If a user already has an active subscription with us that pays automatically, and gets this invoice, they are going to get confused and subscribe again-- creating multiple subscription confusion/over-payments.

[MACscr]

So does this mean we cant use subscriptions or domains as well?

 

AN INVOICE SHOULD ALWAYS BE CREATED NO MATTER WHAT. It should just remind the user of the charge and tell them not to worry about paying its, since they already have an active subscription.

 

Also, A RECEIPT SHOULD ALWAYS BE GENERATED. Common business practice.

[xxkylexx]

AN INVOICE SHOULD ALWAYS BE CREATED NO MATTER WHAT. It should just remind the user of the charge and tell them not to worry about paying its, since they already have an active subscription.

 

Correct. From what I see, this is not the current case. I use to have the invoices generated and marked paid after the client's subscription went through (for keeping track of payments/transactions). I liked how that worked in v3.3. Now I have users that are getting invoices and emails with buttons asking them to create subscriptions, when they already have an active subscription...

[MACscr]

AN INVOICE SHOULD ALWAYS BE CREATED NO MATTER WHAT. It should just remind the user of the charge and tell them not to worry about paying its, since they already have an active subscription.

 

Correct. From what I see, this is not the current case. I use to have the invoices generated and marked paid after the client's subscription went through (for keeping track of payments/transactions). I liked how that worked in v3.3. Now I have users that are getting invoices with buttons to create subscriptions, when they already have an active subscription...

 

How can you generate an invoice for something thats already paid?. An invoice is a bill, not a receipt.

[xxkylexx]

AN INVOICE SHOULD ALWAYS BE CREATED NO MATTER WHAT. It should just remind the user of the charge and tell them not to worry about paying its, since they already have an active subscription.

 

Correct. From what I see, this is not the current case. I use to have the invoices generated and marked paid after the client's subscription went through (for keeping track of payments/transactions). I liked how that worked in v3.3. Now I have users that are getting invoices with buttons to create subscriptions, when they already have an active subscription...

 

How can you generate an invoice for something thats already paid?. An invoice is a bill, not a receipt.

It was an option in v3.3. For paypal subscriptions, you could have the system automatically generate an invoice and mark it paid after a subscription payment was received. If you didn't do that, then there was no archive of previous transactions made via a subscription (for the client). It pretty much served as a receipt for subscriptions.

[MACscr]

Sry, i knew what you were doing, i just think its dumb that the system works like that.

[robwee]

I totally agree and I have written to Matt about the invoice issue and he seems to think that it's a non issue. I much prefer the previous version also. This invoice thing is confusing my clients as well. Customers should just be presented with subscription up front in the sign up page, customers then goes to paypal and subscribe, then gets an invoice stating that it's done! End of story! Plus the invoicing option just creates unnecessary steps.

[Matt]

There was always complaints that a user was taken to PayPal to create a subscription for each item. Sometimes if users had a product, multiple addons & a domain in an order then ended up going to PayPal 5 times. Most quit before that and it resulted in the need to manually invoice for what wasn't paid during the order. There was also complaints about how it was difficult for them to know how to create a new subscription or pay with no invoices. So there is nothing but benefits to this new method of doing it - invoicing for everything, warns of upcoming charges, creates a subscription that pays for the hosting account recurring and invoicing one time payments for the other items.

 

It also means you can now use all the features with PayPal Subscriptions such as credit so overpaying is not so much of an issue. If your customers can't keep track of if they have a subscription setup to pay it then you can edit the email template and add in a reminder to check if needed.

 

Matt

[mrprez]

If your customers can't keep track of if they have a subscription setup to pay it then you can edit the email template and add in a reminder to check if needed.

 

That's the part that doesn't work. Where in the client details area does it tell them they have a subscription? All it says is PayPal.

 

For me, I like the way the new system works, we just need to be able to somehow breakdown the PayPal payment method that so that if they have a PP subscription ID in their record it shows that the payment method is PP Subscription and not just PayPal.

 

John

[xxkylexx]

I understand the idea behind the new system, and see obvious benefits. However, I still think it needs some refining.

 

My only fear is that I am going to have to manage multiple subscription creations due to people not understanding their payment is going to happen automatically (usually after their first couple of bills or so). No matter how many times you tell them, there is always going to be the ones that don't read and do it anyway.

 

One idea that would help solve my problem would be that if the subscription field on their account is populated (meaning that client is obviously using paypal subscriptions with you, and not manual paypal), then do not display the subscription button in the invoice/email. Instead, display just a short clause such as "It appears you are using a PayPal subscription with us. You will be billed automatically via your active subscription". Or display the clause and a button that says "Pay Anyway".

 

I know this probably isn't a solid solution, just my idea.

[robwee]

Thank you Matt for your input and is much appreciated. I have never met anyone who is so dedicated in supporting their offerings - So kudos to you!

 

Back to the PayPal issue. I can certainly can see the benefits of the system, but as a business owner I know for a fact that customers don't like to read and when they purchase an item, oftentimes they are driven by impulses. The invoicing system is not as straightforward as one thinks, and also there are no clear instructions and quoting mrperez -

"That's the part that doesn't work. Where in the client details area does it tell them they have a subscription? All it says is PayPal."

 

The Paypal invoice system needs to be "dumbed down". Customers shouldn't be force to figure things out on their own.

 

I am not posting this because I like to or just want to make a case, this stems from customer complains on my website. No matter how a developer thinks his or her new features are suppose to help and improve things, the TRUE TEST at the end always lies on the end-users experience.