i'm going to explain the flow of what i need:
the checkout process is the same, now, in the last step, i'm doing POST to an external URL, where all the data is processed, i wait to the response of the external server, after process it, i make the correspondient step, 1- Save the order in the db or 2- Give an error message. it depend on the response, then, to save the order i need to have all the card details, if i don't have it, magento give me an error, the external server doesn't return the card details for security reason, and they said the won't, so, i need to keep alive all this information until i can save it or refuse it, my question: What can i do here? Save the card details in a cookie? or a session variable?? or do i have another opcion??
thanks
If you save card details anywhere, including the session, you will probably have run afoul of data security laws in whatever country the business is running in. I would not suggest that as a solution.
As this is a really important topic (imo) and the answers are a bit complicated i decided to write a rather lenghy response about this.
So what are the main aspects with custom payment methods and especially with magento?
You are most likely not allowed to store and or transmit credit card information.
However you can store something similar so the customer doesn't have to re-enter his/her information all the time. I will come to that later.
Magento is a very flexible and powerful application (however it is damn slow). You can do almost anything. But when it comes to checkout processing the flow has to obey certain limitations, with good reasons.
Checkout processing steps should be capsulated into units. You are trying to wrap apart one unit which is almost certainly a very bad idea.
So what I want't to say is that the Credit Card information should be entered at the SAME provider that processes the payment. Nothing else. Ever.
I mean thats just absurd... Think about it. "Please provide your paypal credentials, we will then do the payment for you..."
On the other hand if you are a certified credit card payment provider you this transaction of yours (which sounds absolutely insecure) is handled internally and you as a provider are like a black box. Even for your shop.
If you really want that you can internally do your verification transaction etc. To get you on the right track with that i have this code for you which should bring you on the right track.
I essentially copied it from magento forum and tweaked it a bit to work with the usual issues like several shops, super products, custom prices, special prices and so on.
However i think you should really re consider your approach for whatever you are trying to accomplish.
Last but not least as i mentioned above, there are way to "store" the card information at the provider. For example Ogone offers you the possibility to send a customer token along with the customer, and if the same token appears again they just pre-fill out all the information and the customer just has to click "pay".
They also offer you to customzie the payment pages and have your own vohst so that the user essentially doesn't realise he/she is even leaving your shop.
They also have steady modules for magento that work like a charm and are pretty customizeable.
Maby thats what you want...
If I didn't answer your question, at least in an indirect way, I would kindly ask you to re write your question and put more clearly what you exactly wan't and expecially what your intentions are. Meaning what you are trying to accomplish in the end. Perhaps there are better approaches!
Greetings, joe
Related
so I need to ask a question, I need to setup a simple paypal express checkout system, that one can allow users to change currencies, and two can then update the page with the updated currencies.
Then I need a way for me to get the order information. As I will be selling website templates so I need a way for me to get their email address, so I can then email them with the link to the template file download.
So my question is what data do I get if I set up an express checkout system. And what code do I need, Do i need to create a database to get the returned data back from paypal? Or do I just get an email or can i see that when i log into my paypal account and check orders and see their details that way, but the main important detail i need is their email address?
Can I also say that this is the first time I have looked into express shopping carts. So I am a complete novice in this field, So I will struggle with the coding aspect. But I think it is the route I need to go down.
Also I want to make it all in php as well. But also I don't want to use ready made systems. I just need the back-end code so that I can then just implement it into my current design. Not sure if paypal give you the code when you click the express shopping cart option in All tool section. I did notice though it redirects to a page that lists many partner sites. I couldn't find anywhere for any implementation advice or tips or code.
EDIT: Also I know I will also need to use either IPN or PDT but the documentation I read is highly confusing and just is making me unsure if I can even set a system up. I also read that you should implement both systems, but I also read that that had a risk of doing the payment twice. So yeah i am kinda a bit unsure how to even go about implementing a system I need.
Thanks in advance.
I have a <textarea> along with user registration information that I only want to be processed (inserted to the database) after payment (I want to keep my database clear unnecessary registrations or things like people that register but change their mind about paying for the site services)
I mean, I could use sessions but are there any other ways?
I was looking for a gateway that'll pass these variables back to me after purchase.
Or perhaps just having the gateway API.
Now, I know gateways such as paypal allow advanced processes like these but I don't want to apply to their credit checks just in case they have a reason to reject me. I don't want to depend on one gateway, is there any other gateways that guarantee not to reject my gateway needs and allow me to make advanced processes like the ones mentioned above? If anyone knows about gateways that don't need credit-type checks to be accepted I would appreciate if one could be suggested.
Note: I know some people will suggest to keep the registration data since it's only a few kilobytes even if people won't use the site or pay for the services. Call me OCD but I like my database clean and to only have relevant users/data. I will end up doing this in the end if I don't find a solution that suits my needs, so please, don't suggest it. Thanks.
If you want to use simple form based integration, you aren't going to get around having rows in your table before the users has been processed, unless you want people stealing your service. The fact you want your "database clean" is naive. Just put a registered flag and delete periodically if you are really that OCD.
You must create a auth token (random unique string), and update the database of the current user that that token belongs to that user. You then pass the user to the payment gateway and also pass along the token you have assigned to that user.
The gateway will send the user back to a url of your choosing, along with the token you have assigned to that user. At this point you update the table for that user with that token.
Only you and the gateway know about the token, the user only sees it if they get a successful charge.
If you don't do this, anyone can find the url the gateway sends on successful charge, and just load it themselves, giving them free service.
Alternatively, you can use deeper integration, were you do a web service call to the payment gateway, if it succeeds, you update your row, if it fails, you don't. This subjects you to onerous PCI compliance regulations. Trust me you don't want to delve into that. Just avoid it and do not let your systems see any CC information.
I need to build web application where users can sell goods.
Each user should be able to get money directly on his PayPal account.
Can you suggest which PayPal service/payment method (or other payment system) it is better/safely to use in this case?
Thanks in advance
This is easily set up (if I read your requirements correctly). You would have to create your part of the system, but that's obvious.
The rest, specifically vendor payments, could be handled all by PayPal.
PayPal could process the orders into individual accounts. You would simply have to use the same IPN notification file for each Buy Link. This IPN notification file is what PayPal uses to notify an order has come. It does not matter that it may have come TO Suzie's or TO Bob's account.
So, your notification script gets the order -- Then, your internal system differentiates the vendor and ... that's it ;).
IPN is very simple too, and they've got nice templates in various languages to get you started.
I'm sure there are alternate ways to do it, but IPN is what I personally use, combined with a back-end system. I even have another vendor whose plug-in for my product I sell. Money goes directly into his PayPal account by simply changing the recipient email in the Buy URL (or form).
Any competent programmer should be able to handle this with ease. The proficiencies would be SQL/database experience and web coding (any language). That's about it. A non-programmer could probably even learn, though needs to be careful to sanitize the input to protect against SQL injection attacks.
You can use ExpressCheckout, this means that your sellers do not need tho have Pro accounts, but login and payment will occur in paypal's popup window. You can also use more advanced integration, but this might require the merchants to upgrade their account, and this might cost them money in every month.
You also need to collect API keys from merchants and store them in a very safe location, or collect the money yourself, and pay for the merchants using paypal's API code, but this will introduce additional (transfer) costs.
You will most likely have to write it from scratch. I mean, from some bare framework.
I am in the process of writing the final stages of a checkout module using the FirstData Global Gateway API for a client. All the form views for data entry have been created and the controllers are successfully communicating test data with the FirstData webservice.
I am looking for thoughts on best practices on how to structure the user experience for checkout after the 'process order' button is clicked.
I am planning on using javascript to disable the process button after it is clicked and have the information passed to the Web Service during this delay. What are some methods you may have used in the past to create this delay while informing the user that the payment call is being made. What are some methods you may have used in the past to best operate the callback function that notifies if the transaction has been approved or declined? Has anyone found processing all this information in the same script using PHP_SELF for the action, or is it generally better to place this logic elsewhere?
Just some general inquires to help guide the process through a little trial and error. Maybe the response will help collect some pretty good thoughts for everyone's use.
What are some methods you may have
used in the past to create this delay
while informing the user that the
payment call is being made?
You don't want to delay the process any as processing the payment will incur enough overhead for natural delay to occur by itself. Your goal at this point to prevent duplicate submissions and let the user know something is happening while they wait. Disabling the submit button is a good idea. Also, creating a unique key for that checkout process that also needs to be submitted with the order is a good idea. When they submit their payment you check for that key and make sure it is there (usually it is in a session variable). If it is delete it and then process the transaction, if they submit the form again it will then be able to be flagged as a duplicate transaction.
What are some methods you may have
used in the past to best operate the
callback function that notifies if the
transaction has been approved or
declined?
The payment gateway is going to return an approved, declined, or error value. Nothing fancy so there's really no fancy handling required. Approved transaction should have all relevant order and database information actions performed and then the user should be taken to a thank you/receipt page. Errors and declines can be handled in a similar ways with the user being presented with the checkout page again. If the card is declined let the user know politely that their bank declined the transaction and invite them to use a different credit card. If there is a processing error you can either ask them to try again or direct them to contact you by telephone to place their order.
Has anyone found processing all this
information in the same script using
PHP_SELF for the action, or is it
generally better to place this logic
elsewhere?
Tomato, tomáto. It all depends on your programming style. Having the payment process on the same page as the form is fine. I've done it. All that matters is that the payment is handled properly and the user sees what they need to see. What happens in the background doesn't matter to them.
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.