I have to preface this question by saying, yes, I am aware this is a little of an open ended question. Feel free to let me know if you want it removed.
I am currently developing a module that would implement Alipay to OpenCart. OpenCart comes with various payment gateways such as Amazon or PayPal, but since we are targeting the Chinese demographic, we have to use Alipay.
I have successfully implemented the Alipay framework to my dev/staging site with dummy data and products, so I know I am able to make valid requests and pay real money to our customer's account.
Here is what I am need of a little assistance - I am not quite sure how to implement my existing Alipay API into OpenCart.
Here is my Alipay file structure at the moment:
alipay_index.html. This is my Alipay index file which contains hidden dummy data such as the item name, price, transaction number, description, etc. This data would come from a MySQL database in the future.
alipayapi.php. This is the page that generates the request (using POST from the various inputs from alipay_index.html), and sends the requests to Alipay's API files under /libs/.
Within /libs/ is a PHP file called alipay.config.php which contains all the sensitive information such as our Alipay Partner ID, MD5 hash key, various certificates, etc. Under /libs/ is also various Alipay API files such as notify_url.php, return_url.php, alipay_submit.class.php (which builds and sends the request URL).
From my understanding, OpenCart allows for the editing of module information in admin, that allows modifying attributes such as "which layouts to display the module on, whether it is enabled or disabled, and any module specific options", taken from the OpenCart docs. I can imagine the information of alipay.config.php being in this edit page, so administrators can change the partner ID, key, and certificate location, etc.
My question is - I am entirely not sure where to start. I have completed the Hello World tutorials that one could find online, but since I am dealing with the Alipay API and so many different inputs, I am quite lost. Could someone with OpenCart experience give me some pointers on what steps I can take?
OpenCart is implemented in some kind of MVC pattern. In order to implement a new payment module you could take a look at any of the already existing (bundled) payment modules. Pick any of them or more of them that could suit you the most and start by copying and editing it.
The payment module files are located at these folders:
admin
admin/controller/payment/ - controller classes
admin/model/language/<LANG>/payment/ - translation files
admin/view/template/payment/ - templates
catalog
catalog/controller/payment/ - controller classes
catalog/model/payment/ - model classes
catalog/model/language/<LANG>/payment/ - translation files
admin/view/theme/<THEME>/template/payment/ - templates
Pick e.g. PayPal, copy it, rename to AliPay, rename each occurrence of paypal to alipay within the files, add/remove setting options and off you go ;-)
Related
currently I'm working on my own, selfwritten Website (from scratch, without any CMS or sh**) and I want to implement a special system for the Commissions I make.
Some people are commissioning me to create 3D Models and other stuff.
Since sometimes my customers are from a different timezone (I'm from germany, most of my customers are from america) communicating over Discord sometimes fails because of that.
So I thought about creating a system to let the customers download their commissioned model as soon as I've uploaded it and sent them a Code to "unlock" the download to it.
I thought this probably could work using Paypal. They get the Code, enters them on my website and gets the information to pay a specific amount I've setup before. After they paid, the download is unlocked.
Any Idea how I could setup something like that?
Thank you in advance!
I have a production_db and a copy of it, a test_db, where I develop, test new feature, solve problems, ecc. So, sometimes I copy the production_db on the test_db, but here's the problem: I know that Api Username, Password and Signature are stored in the rules_config table, in the data column of type blob, so when i do a copy of the DB, these configuration were copied, and i have to enter in the PDC, go to the PayPal Module settings (both PayPal Express Checkout for PayPal account and credit Card) and then change the values of the API with the sandbox account one.
The question is: I need a way to read PayPal's credentials from a configuration file instead of DB, but I don't know how and if it's possible. I tried to figure out how this data are collected and used in the deep of Drupal, so i can intercept the DB call and put me in the middle of it, but with no success.
Someone have or had the same problem?
Thanks a lot to everyone!
First Identify where your database call is happening, I guess that should be in your PAYPAL module.
Write one YAML file to store your paypal credentials. Now use the YAML function to get contents from the files. Drupal supports YAML naturally.
https://api.drupal.org/api/drupal/vendor!symfony!yaml!Yaml.php/function/Yaml%3A%3Aparse/8.2.x
Hope this helps.
this could possibly be answered somewhere allready, but unfortunately I could not find the answer that would suit me.
The question is, can Magento be used only as a front end E-Commerce platform? That is read product nad customer data from external API, and also submit that data to external API. The trick is that it has to be done in real time, not via sheduled tasks.
If there are any Magento plugins that would allow for this, could someone mention any specific names?
Also, how complicated is adding custom functionality to Magento, without "hacking" the system (Things, like multiple shop branches, product sets, that can be enabled per branch, limiting orders to cetain amount of slots per hour etc.)
The entire Magento code base uses the Magento database tables for generating the frontend display, so there isn't really any way around it unless you plan on doing a rewrite on every core model to perform the necessary logic (i.e. fetch from/update external source). Existing solutions to this problem generally use the SOAP API and cron jobs to mirror the data (mapping as necessary to get it between the different structures) on both Magento and whatever external system you're using. You can achieve real-time results using the Magento observer system to send updates to your external system by listening to various model save events, and similarly create a SOAP API call when data is updated on your external system (specific implementation details depend on the system) to keep them in sync in real-time.
I'm trying to make a shipping module for Itella SmartPOST and Post24, it's unlikely you've heard of them as they only exist in Estonia, Finland and maybe somewhere else. Here they give a short overview on how to communicate with their servers in English http://www.smartpost.ee/automaatne-vaikepaki-andmete-saatmine, I guess for a experienced developer it should be enough, but I could use more directions, I really don't want to pay money for the shipping module if I can make it myself.
I've read through couple of tutorials on how to make shipping modules, but none of them cover how to communicate with external sources.
So I guess I need to build something that at the checkout would give the costumer option to choose wich parcel terminal they want the package to come and then send that information with other mandatory fields(http://eteenindus.smartpost.ee/data/_tables.db.html#orders) to Itella and then get some info back from them. I hope I understood this correctly...
So how would I go about doing this? I pretty much understand how to make custom shipping methods, but the part of sending information between mine and their database gets confusing.
Their documentation says they can accept a JSON Post or an XML post request, which means you would have to generate these requests and send them from Magento.
I suggest looking into tutorials on creating API based shipment and payment extensions.
Here is a tutorial for an API based payment extension. You can adapt the sending/receiving principles to your shipment extension:
http://www.excellencemagentoblog.com/magento-create-custom-payment-method-api-based
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.