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.
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.
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!
I am new to Drupal. I have a book-publisher website, which is not an onlineshop but that displays numerous Books. They now want to integrate a a pre-order button for one specific book. I figured out the best way and quickest way to do it is to use paypal express checkout. However, the paypal express checkout module just works with Drupal commerce, which is not installed, and I am not sure if it would be viable with all the book items they already have. What would be the best way to integrate paypal express checkout just for that one specific book ?
The best way to implement anything in Drupal is to either use an existing contrib module or to create a custom module.
In addition to the Commerce Paypal Express Checkout (which I guess is the one mentionned in the question), which require Commerce to be used, you could also use the PayPal for Payment module, which only require the simpler Payment module.
Out of the box, neither solution will provide a complete working solution.Commerce require lots of configuration. The Payment Form Field module bundle with Payment may be enough for you needs and is easy to configure (add a field to a Content type). But more complexe needs usually require a custom module build with Payment API.
A third option is off-course to implement the PayPal payment yourself, in a custom module.
Go to Getting Started With Express Checkout and have a look at the section titled "Implementing the Simplest Express Checkout Integration". However, this is not the simplest way. A standard PayPal "Buy Now" button would be the simplest way. Go to Single-Item Payments – Buy Now Buttons to read how to do it.
I've built an Ecommerce site in Silverstripe and I'm new to this, sorry if I ask something silly. I'm just wondering how do I implement payment gateways to the Ecommerce site in Silverstripe? Do you have any good tutorials that I can follow?
Thank you very much. By the way I'm choosing DPS as the gateway.
Any recommendations for me to start this would be appreciated.
You may want to start by looking at the Payment module for SilverStripe.
http://www.silverstripe.org/payment-module/
https://github.com/silverstripe-labs/silverstripe-payment
In my opinion payment gateway these days provides so much facilities that all we need to do is to redirect user to the payment gateway with certain attributes like amount,curreency and some other attributes being required by the gateway.
once payment is authorized payment gateway redirect user back to your page.Now almost all payment gateway work in two ways
Synchronized call
ASynchronized call
in the second method you have to provide some entry point to the gateway where it will send you the all required information about payment.
Once you have everything all you need is to do final checkout process for the user.Beside the silverstripe payment module i will suggest you to go through DPS documentation as they might have shown some samples how you can communicate with them and what they expect from you in the request what its structure should be and what they will send back once user done with payment,response structure etc.
I tend to follow this approach once we decide the payment gateway go through there documentation set up a test account with them and than start playing around.
got a question and I hope this is right place to ask :).. don’t quite understand how payment works in magento.
client goes to checkout and lets say wants to pay as a guest, so provides address etc. and finally gets to payment methods. Then I want clients to pay thru credit card. Already have module installed for gateway (bank?) of my choice. At that point I would expect users to be redirected to 3rd party page (bank hosted) where they giving all the details, only after being returned to my magento site with appropriate message.
In magento however it seems like they need to provide cc numbers and details on magento checkout page. I don’t understand if I (or the payment module I installed) need to transfer then all the credit card details to bank? I would have to have checkout page on ssl connection and static ip right?
The thing is I want to avoid touching CC numbers at any point and would love to have it done by a bank page. I like the idea of magento interface all the way without redirecting to another page though, the only problem is not sure if would be able to set it all up properly.
If anyone could explain to me possible options, what is the common way to do it and how the whole process works that would be very much appreciated.
I did my research and looked all over google and various forums still need someones help though. Please let me know if some parts of my question are not quite clear, will try to better explain if necessary.
Had to develop a payment module for DPS in NZ some time back. How this works is, you go to pay on the site and the payment module php code runs that sends off the details to an acquiring institutions payment website who process the transaction for you with the bank. In my case as I recall it was DPS NZ via some soap calls. The Soap calls contained details such as the total cost, the currency, the merchant number to identify who you are paying. The acquiring institution (DPS in this case) then takes your credit card number and expiry date and do the processing. Then, again via some soap calls back to your own magento website you get redirected back with the error code - success, etc.
DPS use soap I think, but other payment websites may use other protocols to work. The other possibility is that your credit card acquiring page could be hosted on your website and you accept the credit card numbers and do all the processing within magento to the acquirer.
In short, the process is controlled by the payment module itself. If you want to see more detail, have a look at the payment module tutorials that are available and also the comments in the magento forums. You can also look at the paypal module code.
The default architecture that Magento payment modules use involves the customer interfacing with the module and the module talking to your payment gateway behind the scenes.
Basically the customer inputs all his data (CC and all) and hits the payment button at which point certain functions are run in the chosen payment module. What these functions do is entirely up to how the payment gateway works. if the gateway talks via XML they send/receive XML, if it needs SOAP then they use SOAP and so on and so forth. This in fact is the gist of building a new payment module. Open an existing one, check out which functions are called, get rid of the code in there and substitute with your own that will talk to your particular bank/gateway.
Of course some gateways have an alternate way of operating where you send the customer to their pages, he gives them his CC data and he is promptly returned to your site. This way you don't need to worry about handling credit card data, but unfortunately the process of implementing this in Magento is somewhat more involved.
If you need to use a certain gateway then you should first check whether a payment module for it already exists. if not you can download a similar payment module, dissect it and modify it to run your code where appropriate.