I have a maintenance project which uses Authorize.Net for payment. Currently, the system provides an email receipt provided by the gateway. Is there any way to grab the receipt and display on the thank you page as a printable receipt ?
Help would be appreciated.
Not realistically. It's hard to say exactly how you would do this since which API you are using will affect your programming, but technically you can pipe the copy of the receipt sent to you into a PHP program which would then place it into a database or flat file. Meanwhile you can have your PHP script waiting for the file or database record to exist and, when it does, output it to the screen.
This would be a bad plan for several reasons:
If the email never arrives your user could be left waiting for a receipt that never comes. That could result in unhappy users and potentially chargebacks.
Even if this works it will be slow which will also result in lower customer satisfaction.
This is a hack.
There are much better ways to provide a printable receipt to your users. If you're using the AIM, ARB, or CIM APIs you have instant access to the response from Authorize.Net. You can easily generate your own printable receipt for them with this information. If you're using SIM you can use relay response to get the transaction information from Authorize.Net to accomplish the same thing.
These are better solutions because:
They're fast. You will get a response from Authorize.Net within seconds and can print out the information in less then a second.
You have total control of the receipts content and appearance.
It's reliable. You can count on getting a fast response every time.
If working with APIs seems daunting to you, you may find using their Silent Post feature appealing. It's just like Paypal's IPN where after a transaction is processed, regardless of which API you use, all of the transaction information is sent to a PHP script you specify. It is POSTed just like a form submission so it's easy to work with. You can then email your users a receipt with that information.
Disclaimer: I wrote the Sitepoint chargeback article and the Silent Post article
Related
I am integrating PayPal Express Checkout API into a digital goods/services website. I worked out all the technical stuff, but now I have a theoretical question - when the transaction is done and I get a confirmation from PayPal, what is the best way to store that acknowledgement from paypal, and credit my user's account?
The ConfirmPayment() function in the paypal library returns from paypal with an associative array, including a transaction ID, and acknowledgement that I have the user's money in my business account.
So my plan is, store that transaction ID as a unique value in a SQL table, so if the user for example reloads the confirmation page, which would then re-call ConfirmPayment($token), my PHP script won't just credit their account a second time, because the SQL table will return a unique ID error.
How are smart programmers integrating this last payment confirmation into the rest of their application?
THANKS.
I would do it like so:
Keep a full log of all the messages your receive from Paypal. Just the RAW data should be fine. Then beyond that point don't need that much traceability. If anything ever happens you can check the log. This should really never happen, if you need to look at this log a lot to resolve any issues you have a different kind of problem. This is why my suggestion is: don't put too much time into it, but make sure you have traceability (albeit a very crude one).
If the user reloads the confirmation page, Paypal will not send you another message. Keep in mind that you should only accept transactions that Paypal has verified. The user should not be able to validate his own transactions by bypassing Paypal.
I am developing a crowd-funding site (similar to Kickstarter) using the CodeIgniter framework.
I "successfully" implemented PayPal's adaptive payments using this library.
But, I'm just not sure how to correctly and securely check for succesfull/failed payments and witch data is important to save to database.
Note: it's a chained delayed payment, I am the primary receiver, and the secondary receiver is the crowd-funding project creator. The money is transferred to the secondary receiver after a predetermined period of time.
The flow I have right now goes like this:
User click to buy a reward.
I use the 'Pay' API operation to request payment (unique TrackingID included) and save the request in the database.
If the request is succesfull, I save some response data in the session (TrackingID, PayKey, amount, ...) and redirect to PayPal..
In this step the user can: accept payment, cancel, or just close the browser, so I dont really know what happens here... (recommendations?)
If the user accepts the payment, he is redirected back to my site and I use data I saved in the session to request a 'PaymentDetails' API operation to obtain information about the payment.
I save the result in database and check to see if the response 'amount' is equal to the request 'amount' (for security).
If everything went OK I update the database and connect the payment TrackingID with the user and the reward he bought.
Later (can be months later), the 'ExecutePayment' API operation is requested by an admin, and the money is transferred from us to the project creator, and we take a small fee (thats how crowd-funding works...)
Now, I'm sure I'm missing lot of things but I have no idea what:
What about the IPN API? I need it? Where it comes to play inside the flow and checks?
What I do if the user closes the browser window when he is in PayPay (out of my site).
I heard that the PayKey is valid for 3 hours, how can I 'ExecutePayment' after months?
How I handle the enormous amount of error types in the PayPal API?
Any tips or examples of others things I need to take care of? Security? Errors? Others?
Thank you very much, I really need your answer!
IPN will automatically POST data to your "listener" (which you'd need to develop) in order to automate post-payment procedures. For example, you could update a database, hit 3rd party web services, generate email receipts, etc. within IPN so that those events happen automatically any time you receive money in your PayPal account. You can also set it up to handle refunds, disputes, and other events. It's not required, but often very useful.
This is one reason IPN can be useful. IPN will be triggered whether the user makes it back to your site or not. If you're doing post-payment processing procedures within your thank you page or something like that, I'd recommend you move it into an IPN solution.
The PayKey is indeed valid for 3 hours when being used as a token. When you call Pay with an ActionType of CREATE, though, it sets up a delayed payment and the PayKey is then valid for up to 90 days.
The error information will always come back in the same format in the response. You can just log or display errors accordingly based on this standard response.
Sounds like you're pretty much on top of everything for the most part.
I've been curious about this for awhile and could never find any good information. I used to work at a pizza place that did online ordering. The user would submit their card information and we would run it at the store. I was wondering if someone could give me an idea as to how this transaction took place. If it was PCI compliant, and how it would be sent to the printer. I could think of a couple ways but none of them really seem to be the correct way. I'm looking to do this in PHP. Thanks.
If I where to design this system it would be like this:
The customer posts the order and CC information using a webform over a secure link to the server (using php to generate the page and take the info back in).
The server would use a payment gateway and bill the card on the server (server side PHP script).
On a successful billing it would contact a application running on a box at the restaurant with what to print on the order ticket (only the last 4 digits of the CC info is sent to the restaurant)
Updated with Chris's suggestion
Another option is to use PGP to encode the credit card on the server with the public key. When the CC is sent to the store, it can the be decoded with the Private Key and viewed in order to charge it. But when you are passing credit card information around like that, you always run the risk of something going terribly wrong. It's always better to use a gateway and charge the card immediately or authorize the transaction and then go back and collect the funds by running the authorization number.
I'm a web developer looking to move a lot of clients to use authorize.net for their CC processing. I have used authorize.net once in PHP doing SIM integration for a simple site.
Now the problem is, some of our clients have established processes that takes the CC info from our site, and it goes through a fulfillment process outside the control of our site. In at least one case, the client uses the CC info to bill for shipping after it's packaged, long after it leaves our website, because of international rates.
The main reason of using authorize.net is security. We want to be PCI compliant so the idea is that the CC never even goes through our web server. It is entered on authorize.net and never leaves there. So I need to figure out the API to conduct this process.
So my question is, without ever handling the CC info, how do I create a "pending" transaction that takes the user's cc info at one point, and then has the cost updated at another point? I am picturing I will have to tell the client to log back into our site (or authorize.net) to update the cost of the order.
All I have found is this FAQ, my question is the same as the top, but it isn't clear if I have to keep the CC info to do this process, which I simply cannot do.
http://www.inventiveweb.com/RoboCharge/faq.htm
Can it be done?
OK they have great support at authorize.net and an excellent knowledge base. I bet their support guys just paste out of the database.
As outlined in the link above, if you know the high-end of the costs, you can pad, and do an AUTH_ONLY followed by a PRIOR_AUTH_CAPTURE.
As of now there is no API for this, but you can log into your authorize.net account and perform a re-bill. Transactions are stored for up to 90 days, so you can then issue a new transaction with a re-bill and you don't need the CC info.
The downside? A re-bill only works on a successfully settled transaction, and that takes 1-3 days.
I currently have a php script that reads email messages sent from phones and then it posts them on the internet...
I want to do the same thing but instead of reading emails, I would like to process the data through a SMS.
so, if someone sends a sms to X number, my program would get the message through this X number and use it in the site.
What would I need?
You have a lot of options here. Generally speaking you need to first acquire the number that people can SMS to. Afterwards a callback will be issued to you when someone sends and SMS and your PHP script can process the message and figure out what to do with it.
You essentially have a few options for exposing the SMS
Go with a dedicated short-code. Eg someone sends a text to 53234 and you will get a callback to deal with it. This is an expensive option. It will cost you generally around $2500/mo minimum not including per messaging fees. You can requisition a short code through a provider such as Open Market. You have to get approval for the short code which might take as much as 6 weeks.
Go with a shared short code. This is a bit cheaper -- you pay per message and it usually costs anywhere from .02 - .10 /msg depending on your msg volume. You get a keyword such as DOLLY that people have to preface before texting. So they would text DOLLY INPUT TEXT HERE to 53234 now and you would receive the callback with INPUT TEXT HERE. Celltrust and others provide shared short codes.
Use a public api that allows people to text in through something such as TextMarks. Textmarks is like a shared short code requires keyword usage + users to subscribe. However it is free which is great and has a nice callback API. I believe a service called Mozes also provides similar service. Finally, if you want you can set up a Twitter account and have people text to their number. Facebook also a similar API that allows you to use their FBOOK shortcode.
Ish's answer was great. I'd like to point out an additional free option.
Most carriers allow you to send SMS messages to email addresses. The SMS text gets inserted into the body of the email and the subject is carrier dependent. Once the email is sitting in your inbox, you can access it by the method of your choice.
This method has worked for me in a personal project requiring remote communication with my computer when all I had was a cell phone without internet capabilities.
This Wikipedia page shows how many carries support this (practically all).
Just try not to violate anyone's terms of service, you could always host the email account yourself.