I'm working on a custom WHMCS payment gateway module for the Mollie payment gateway. So far I integrated one-off payments with no issue, but I'm having some trouble implementing recurring payments.
The flow for either a subscription or authorization to charge the customer on-demand differs slightly.
The flow for creating a subscription is:
Create a customer profile in Mollie
Create a mandate by performing an authorization payment - used to link a payment method to a customer (must be a payment of at least €0.01, requires user input)
Add a subscription to a mandate, telling Mollie to charge the associated card x amount every x days/weeks/months
The flow for authorizing the merchant to charge on-demand is:
Create a customer profile in Mollie
Create a mandate by performing an authorization payment - used to link a payment method to a customer (must be a payment of at least €0.01, requires user input)
Merchant sends a payment request to Mollie for every new invoice
The problem that I have is that Mollie supports multiple payment methods per customer. While WHMCS has built their gateway module system around single-method gateways such as Stripe.
What I want to do is replace the credit card management page with a custom page (preferably generated in the module, without modifying any templates) that allows customers to manage their Mollie details. This would include seeing active mandates and adding new ones (again, a mandate is basically an authorization for me to use a specific payment method for subscriptions or on-demand charging).
I could not find any way of doing this in the WHMCS documentation. Is this at all possible, or should I accept that the only way for customers to see the pages generated by my module is for them to go through an invoice first.
You are going to need to create two modules that work together, a payment gateway module and an addon module. The addon module will allow you to create client side pages where customers can enter agreements / adjust agreements and then use the _link function to display a form where clients can pick which agreement to use when paying the invoice.
Seems perhaps useful to mention for consideration that WHMCS does already support recurring payments with a mature and native UI and integrates it with good invoicing practice. The customer is sent an invoice ahead of the payment, then on the due date, the card is charged and the customer is sent a receipt. Customers can see an audit trail of these invoices in the system.
While the business and charging needs of applications vary immensely due to a variety of driving reasons, I would think that for most people implementing recurring payments using WHMCS's recurring payment is a simple and effective solution. Remember, WHMCS lives for these - as just one example, it works brilliantly well with recurring paymentsfor hosting and domain renewal; the domain is simply not renewed and reminders are sent until paid; and any hosting will expire if not paid and eventually be optionally deleted from the server. It's always going to be harder to craft these sorts of automations with subscription-based payment system - even if a webhook is triggered on successful subscription renewal. (It can be done, it's just harder and less reliable than native - what if the IPN/webhook doesn't arrive reliably, or other issues break things). I'm just advocating that any new readers consider doing this within WHMCS's very capable and time-tested recurring transaction framework for this - I think it's worth at least considering, and hasn't been mentioned above, unless I missed it. I'm also mentioning this because for those who are newer to WHMCS this may not occur as a good idea immediately. WHMCS is all about making recurring transactions easy, letting customers see an invoice trail, etc.
I realise that it is now 2022 and that this discussion was originally held in late 2016, but wanted to add this to the great ideas above for new readers.
Apologies if this is annoying; again, fully realize that legacy decisions and business factors can make it essential to stay with external recurring payments!
Related
We currently have a website that uses eWay token payments and setup Auto Order for customers. They can manage what items are in the auto orders and at what frequency the orders will be placed.
After the first order we can save the users 'Token' with eWay and charge their card at each instance.
We would like to add in the ability to pay with PayPal, but cannot see a similar feature where future orders can be placed without the user interacting.
The issue is that the price may differ from original payment, as discounts for the item may change or the user could add in other products to the auto order. So we don't want to have a repeat purchase setup in PayPal, rather automatically charge the users account when needed.
Been looking through paypal API docs and nothing is jumping out as the correct way to proceed.
We have tried payments through eWay to PayPal however they are not supporting paypal through their gateway anymore so are not much help.
Our website is PHP, Mysql driven and we currently use PayPalExpress checkout API for single orders.
For PayPal, the receiving account needs a feature called "reference transactions". This is not enabled by default in the live environment (though it is in sandbox). It requires business approval, so the PayPal account owner should contact PayPal's general customer support or an account manager (note: not technical support) to discuss the business need for the feature.
Once approved for the "reference transactions" feature on a live business account, PayPal can guide you on which API to best integrate to make use of this. Something like v2 or v3 vault and that API's payment tokens are a possibility that sounds exactly what you are describing, though there are other (older/legacy) APIs that use something called a "billing agreement" as what's effectively a token as well.
We want to integrate Paypal and Authorize.net payment gateways into Magento.
Can we do like just take Credit/Debit card details from customer and redirect to one of those gateways automatically for further process ?
User will not select either to go with Paypal or Authorize.net
You cannot just take the credit card info and then forward to a provider of your discretion.
First of all, PayPal does no longer allow payment without registration (at least in quite some important countries like Germany). Second, you would need to do PCI certification, which is very expensive and time consuming (because you process the credit card data on your servers).
Technically, it would probably be feasible, but you would most likely have to heavily extend or hack Magento.
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
Let's say, for the sake of discussion, my client does not want to use the Paypal api for transactions. I have already made a shopping cart. The user submits the items on the shopping cart and their credit card number.
Assuming I'm not using any api, how would I then charge the user's credit card for the items on the shopping cart? I understand that it is complex, just wondering what the general process is like and how to get started.
You're going to need to trigger a bank transaction, so obviously you're going to need to use an API at some level. I think the way to go would be to first learn in some detail how at least one of the popular commercial (by definition?) payment card processing services works, e.g.:
https://paymentvision.com/Payment-Gateway/Payment-Gateway-API.aspx
http://aws.amazon.com/fps/
https://www.firstdata.com/en_us/customer-center/merchants/support/first-data-global-gateway-api-software-landing.html
http://www.authorize.net/
The next step would be to design the "payment processing" subsystem of your PHP application/library around the "backend workflow" (perhaps using a 3rd party PHP library, if one is available), and do some testing.
Then I would plan for a security audit of your code & systems before you actually use it to handle payment card information on behalf of a customer/3rd party.
You can also capture all the card information and use an external payment processor. The problem is that you will be hit with major fees since it will be considered a keyed in and not swiped transaction.
If you don't want/like paypal, don want to use a payment processor like authorize.net, you could look at other options like stripe.com.
Find an payment gateway, such as authorize.net. With payment gateways such as this, your client will need to sign up for a merchant account with a credit card processing agency. You payment gateway can help you with this.
Then, you'll usually get a token or api key that you will use to connect to the payment gateways services. From php, you'll use cURL or fsockopen to connect to them. Securely send your api key, get a response, then send some other required message, get another response, and then send in credit card information and credit card holder information.
There are lots of PHP Libraries to choose from out there for different payment gateways. I'm not suggesting authorize.net, it was just an example. But when you find one you are happy with, and happy with the fees that are associated with processing credit cards, you can either use a prewritten library, or they payment gateway will provide you with and API that will tell you how to integrate with their system.
Payum efficiency proved by 1k+ stars on a GitHub, great comments and a million of downloads. Supports 50+ different payment gateways so you surely find what you need.
Interested to know if (a) this is possible, and (b) whether any of you have successfully implemented the functionality. The wiki page repeatedly refers to "Currently, by default, Magento supports purchasing items with recurring profiles only for the PayPal payment system and only through the Express Checkout method." - I'm not sure if that's because there are no payment other methods currently implementing the Interface, or because they've hardcoded the architecture such that it will only work with Paypal.
To test this, I've created a payment method that stubs out the Mage_Payment_Model_Recurring_Profile_MethodInterface methods, and that payment option is now presented when I go through checkout with a Nominal product (i.e. product with a recurring profile) and the order is placed successfully. However it doesn't appear in the list of Sales>Recurring Profiles or Customer's Billing Agreements. I guess they will be populated by the stubbed-out methods.
I suspect that the fields in Mage_Payment_Model_Recurring_Profile are setup to mirror those required by Paypal, so it may take some mapping to translate those into another payment gateway's requirements, but that should be achievable theoretically, possibly using a model override.
Sorry for the rambling question, but I'm keen to hear your experiences since the framework seems to support it on first investigation.
Which country are you in? With some adaption of the RBS WorldPay module you can use RBS FuturePay which is geared around repeat payments. I only had to use the module to take two 50-50 payments, however, the FuturePay technical support was brilliant and the Phoenix WorldPay module is not bad either (as starting points go). Getting it to integrate into Magento's Recurring Payments profile is not something I needed to get to work, however, you could put some other form for people to cancel an order.