I have been looking at setting up web applications that rely heavily on the ability for users to frequently and substantially modify subscriptions. I may be using marketplace features as well, and I need a system that supports both seamlessly.
I have seen multiple horror stories about the complexity of modifying subscriptions, including double billing, or cutting users off at the wrong time.
I sincerely hope, for instance, that this article http://talklikeaduck.denhaven2.com/2007/09/02/how-to-cure-the-paypal-subscription-blues
is out of date. The use cases that I have in mind are even more complex than the ones that he mentioned. For a sampling of what I would like to do:
Support multiple subscriptions and
subscription types/levels. For
instance one user might have 1 Plan A
billed monthly at $10 and 10 plan C
billed at $50 per month and 1 Plan D
billed at $100 per year.
Support changing of arbitrary payment amounts. For instance, user was on the $40 per month plan, but then changes that to a $100 per month plan. Then cancels, then signs up again at $50 per month before the $100 period was up. The user should still get $100 of service for the month that he paid $100 for, and then should change to the $40 per month plan.
Allow for payments of subscription amounts between my users. So one user might initiate a payment of 50% of whatever amount he has paid into the system so far. My application will be handling these types of marketplace style operations and these payments should work in the context of subscriptions...
It does not appear that there is an Open Source PHP library that does what I need either with Amazon or Paypal. So I am looking forward to coding this myself. (be glad to be proved wrong here, perhaps a Freemium for PHP?). I cannot use the various subscription services that are available. Because they generally do not support the features above, and because I need to have direct access to the PayPal or Amazon FPS API for later cleverness via marketplace issues.
Which brings me to my question. Which payment platform should I choose for ease of managing subscriptions? Please send me in the right direction, I only have so much time. But I also do not have time to make the wrong decision. Please provide evidence for your preferences, and if possible detail your work comparing the two systems. Google has the only other payment platform and currently their subscription system is in beta.. If you propose some other better system, please provider tons of good reasons, because I need a popular payment engine that people will feel comfortable with!
-FT
I see you asked this question back in December... if you haven't found an answer yet, I have some suggestions based on my experience with a business problem almost identical to yours.
Which PayPal API are you thinking of using? In using the PayFlow XML API, I found it was thousands of times easier to just roll my own subscription service. If the API you're using supports creating 'reference transactions' based on the previous successful transaction ID, you may save yourself a headache by keeping track of users' subscription amounts, keeping track of what's been paid, and creating a billing script that runs on a daily cronjob, checking each user to see if they need to pay (and how much), and then creating a reference sale for each of them.
Of course, don't forget that you have to explicitly ask for users' permission before you start billing them on a recurring basis, and there should be a good recurring billing and privacy policy. One trouble with this setup is that you pretty much need to create your own scripts to manage people's subscriptions and payments -- fortunately, I was tacking PayPal recurring billing onto a web app that already had subscriptions and accounting built-in.
Let me know if you need any suggestions on how to go about this!
Related
Hello and nice day to everyone!
We are currently building stripe integration (PHP), but are facing problems regarding the valid approach.
The case is, that our e-commerce has business model, where you are buying some physical good (usually one item per purchase) and the you pick type of support plan for that item (subscription with trial).
Practically, it shall go like:
you pay one-time purchase
you subscribe to support plan with certain trial (30 days)
after 30 days you got charged
So in the same time you pay for the product and sign for subscription with trial period.
It shall be 3D secure protected, so our customers wont be bothered with authentication when trial ends.
Sadly, we didnt figured it out yet :(
What kind of approach shall we use? Thanks for any answer and your time
I think you need to specify a trial period(one month) when you set up the plan in stripe, then the money will be deducted automatically at that time.
I am currently planning a new website for a local car hire company. They want a form where a user can input their personal details, select the car they want to hire and when they want to hire it etc. They do not want to take any form of payment on the website, but still insist on taking the user's credit/debit card details that they will then process on their card terminal at the time of hire when the customer picks up the car.
I have looked into a few options about how to achieve this, but keep stumbling on the card details gathering point. One option I have looked at is using WooCommerce (I am building on WordPress) along with this plugin https://www.wplab.com/plugins/offline-credit-card-processing-woocommerce/.
I am looking for any suggestions on a suitable and secure way of gathering the card details with this reservation form, with or without the use of WooCommerce.
Do everything you can to avoid taking credit card details, especially in the case where you're not actually performing any charges against them. Otherwise, you open yourself up to a whole new world of pain, the least of which is ensuring that your whole system design is PCI compliant.
I would try to find out why they think they need the card number ahead of time. When the customer gets to the physical location, the business will get a lower rate from the payment processor if they perform a card present transaction, which means it's actually cheaper for them to not collect the number ahead of time. That alone should be enough of an argument to sway them. If they insist on still taking the card numbers offline, hit them with a huge quote to make your system PCI complaint. It is no joke.
Use a secure SSL connection for a start!
Try a Credit Card validator such as https://framework.zend.com/manual/2.4/en/modules/zend.validator.credit-card.html
I have a website coded in PHP that uses paypal buttons/IPN for subscriptions.
The method is limited and I need to replace it with the REST-API.
What the system needs to do:
Accept new user recurring-payment subscriptions
Be able to change plan pricing for new users
Be able to change plan pricing for existing users
Change subscription plans mid-subscription(If a user upgrades from pro to master the price goes up, and the opposite way it goes down).
The price difference between packages is 5$
Give periodic discounts for a limited amount of months.
The questions:
1.) What is the equivalent of recurring-payments in the PHP-API or REST-API? (I'd rather it auto-charges and notifies my IPN if possible)
2.) How can I automatically refund/charge an additional amount when the user upgrades/downgrades in the middle of a month?
3.) Is there a standalone PHP control-panel that can connect to the paypal API to manage the subscription packages + sales?
Thanks in advance!
If you are looking to use REST APIs, the best place to start is going to be at the REST API docs. For your situation, you can use the vault to set up a recurring payment system. You could also use the future payments API, but you will need to make sure you buy DPRP for your account. Contact PayPal Customer Support to enable DPRP.
With the Vault API, you can just create one time payments over and over with the token you get when storing a credit card.
There is an in-depth walkthrough using the SDK on the PayPal PHP SDK Wiki.
To do refunds, you can use the Refund REST API. All this assuming that you would be writing scripts to detect your user downgrading/upgrading. You would just need to store the amount they are paying each month in your DB.
There are some shopping carts out there that are implementing REST APIs. You might need to google search for something like that.
Hope that helps and gets you started in the right direction!
I am working on a site providing software as a service which is billed on a monthly basis.
The software is licensed on a per-user basis and will be extensible via optional standard modules and custom apps that can be subscribed to through an app store.
The customer can alter the number of users, subscribe or unsubscribe modules and apps every month.
Users, modules and apps should be billed along with the base software, thus the billing amount may greatly vary from month to month.
The goal is to minimize PayPal requests for approval and let customers specify an amount that is above the base subscription price so that minor purchases do not require approval by anyone with access to the company's PayPal account (unless the customer limits the amount to the original subscription price).
Which PayPal APIs would you recommend in this scenario ?
As I understood it, UpdateRecurringPaymentsProfile does not allow the amount to be increased by more than 20% within 180 days without explicit approval by the buyer, so it probably would not work if we try to first request e.g. $200, then bill only $100 and later increase back to e.g. $150, right ?
The Adaptive Payments API seems to require the seller to bill rather than have PayPal do it on a regular basis, is this correct ?
I don't know it's help full or not right now, As it is a very old post.
Instead of creating recurring profile on PayPal Server, You can store the customer's credit card on the PayPal using REST API: https://developer.paypal.com/docs/api/#vault then every month you can fetch it and charge it like recurring Payment, Also you no need to worry about how many time customer upgrade the subscription you can manage it on your server end, Or When client is no longer with the services then just remove its card from PayPal.
I suppose Authorize.net SIM method also does the same.
Hope this make sense.
I need a payment gateway for my php application.I am running a software consultancy and employees are from different parts of the world. I have build an application manage invoices and pay money to them. I need this to be integrated with a payment gateway.
My organization is in USA.
I checked with some payment gateways, but they need seller account for each employee.That is not possible.
My direct requirement is the cash must be transferred from my card/bank account to my employee's bank account . I want to pay through net banking,credit/debit cards,wired transfers,etc.
Please help!!
Thank you
If your requirements are such that the employees need to invoice you first before they get paid, I don't know how you can get around the seller account requirement.
However, if all you're trying to do is simply pay your employees, and manage their invoices through a separate system, something like PayPal could work -- I think really any payment gateway could work if you could push your requirements to the point that you simply pay your employees (one process) and handle client invoices through a second process.
Last time I checked, Paypal lets you transfer to family and friends without their percentage charge, which you could possibly bend to meet your employee payment requirement, if you can offload the invoicing piece to a separate system.
First, you don't tell us enough information about your requirements: do you need support for physical goods ? if so - who's doing the fulfillment ? you can't charge a credit-card until the package was sent which makes things more complicate than most people are aware of.
Second, what you're referring to is called the re-seller model. This model is problematic since all the major credit-card companies in the US recently came up with a new requirement: a merchant that processes more than 100K a year should open his own merchant account! (that's part of PCI compliancy required from the processors).
If all you need is to pay your employees, and being able to do so globally, there's a cool company that does just that called Tiplati.
Disclosure:I work for one of the major payment processing solutions called Bluesnap