I need to integrate PayU payment gateway (via Omnipay) into one of my ExpressionEngine2 (2.8.1) websites thus I need to write this gateway for the shopping cart (Expresso-Store) I am using in my project.
To achieve this, I am looking at the other payment gateways that is already included in the store addon and trying to make sense of what is going on there and trying to follow those examples. Unfortunately there is almost no comments in the existing gateways and I would really like to know what happens in each class rather than 'just following examples'. I see that most of these have pretty much the same structure, although in some gateways there is a class or function missing, or the one gateway handles things different to another gateway.
I also know that I need to write an extension to install this new gateway as the copy/paste method is a no no when you need to update your gateway.
My main concern is what happens in the getData() and sendData() functions of the PurchaseRequest class and how do I know which classes/functions to include?
Any help will do. Thanks in advance
This question is probably better suited to the ExpressionEngine stack exchange site, but anyways...
The Omnipay readme has some basic instructions to create a new gateway. A complete example is probably a little beyond a SO answer, but basically the getData() method formats the request to send to the gateway, and the sendData() sends it.
As for integrating with Store/EE, you can look at this Beanstream gateway to see how to create a new extension containing the extra gateway.
Related
Please can anyone tell me how to integrate standard paypal payment gateway in twig template engine(framework) using PHP.
Please help me. Right now i am in big trouble and even i am beginner.
The quickest and easiest thing to get basic payments working on your site would be to use PayPal Standard buttons. You can create them from within your PayPal account profile, and then it just gives you a snippet of HTML to copy/paste into your site where you'd like the button to show up.
Since you're using PHP, if you want to get a little more advanced with the payment integration you could go with PayPal Express Checkout API's instead of Standard. The documentation can be a little bit daunting, however, with the use of my PHP class library for PayPal you can handle everything very easily with nothing more than the knowledge of working with PHP array data.
The payment methods of my country are not listed in OpenCart Extensions.I want to create one from scratch.Is it possible to write one or I have to use ones comes with OpenCart extensions?
I believe you should be able to implement and use your own "payment method" since OpenCart is open sourced. Just need to spend some time figuring out how it connects.
Well regarding your own "payment method", normally you have to do it through a Gateway. PAYPAL is one of the easiest gateway to be implemented in PHP. Just have a try with their API and some of the sample codes.
There are a lot of other options though. This may be helpful.
PayPals documentation is quite confusing:
I need to integrate PayPal API into my website so the customer can pay for a final sum. And im using the sandbox for testing.
Now, technically, i found two different methods of integrating the API:
Without curl - using header('location', $urlwithvars)
With curl https://developer.paypal.com/docs/classic/express-checkout/gs_expresscheckout/
Now what confuses me - is curl only used because you can do a POST call to the paypal server? Because using the first option i also get directed to the paypal procedure and get the JSON response successfully on my notification url.
Im using following library: https://github.com/jersonandyworks/Paypal-Library-by-RomyBlack
Is that enough or should i use the complete curl process like here http://www.sanwebe.com/2012/07/paypal-expresscheckout-with-php
So basically the main question: DO i have to use curl process or is the header-location-url idea enough?
Thanks in advance
That library you're using is actually just using Payments Standard, not Express Checkout. That may be where part of your confusion comes from. This isn't even hitting the actual API's. Not sure if you care about that or not, but I personally prefer the full Express Checkout API as it provides a lot more options and freedom to integrate however you want.
I'd recommend you take a look at my PHP Class library for PayPal, which has all of the actual API's built in. I have a CodeIgniter specific version of it, too. It will do all the API work for you and you can integrate pretty much all of their calls within minutes.
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.