I am kind of a newbie when it comes to online CC processing integration. I am in the Sandbox at Authorize.NET trying to configure my server to process SIM orders where the payment page form resides on the Authorize.net servers and processes the order. By default it looks like the confirmation is on their sites, and e-mails can be configured to be sent to the buyer and the seller. That is all working in the Sandbox. However, I am trying to capture some of the order and processing information on my server using the relay response. My processing page is accessible on my server, although I must say that I have .htaccess limited intermittently because it is still in development. I turn that off when I am testing.
The error that I am getting is:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service.
I can't tell if they are POSTING data to my page or not, and I'm not really clear on what goes on the response page and how to parse the response. I am using the PHP SDK provided by Authorize.NET. The rest seems to be working. I am getting e-mails for the buyer and the seller and the order is proccessed but I'm not capturing the information on our server. What I would like to do is bypass their confirmation page, receive the relay response, create a custom confirmation and capture some of the data for our database. I'll keep digging because I made a fair amount of progress just reading the docs. This one is particularly useful.
Thanks.
I figured it out. There was an error on the page giving a "500" error. I have to say, it is a little strange the way they have it set up. They are POSTING to my page, where I am capturing the POST data, writing stuff to a database, and then creating a custom confirmation message, although it must be via a header redirect because it shows up on their server (their domain is in the address bar). It all works, but apparently, any SESSION variable values are not available to my script in that case?
Related
I have Integrated Paypal using php. I know there is return url ,that means when payment is received it will return to the url for our website.My Question is if payment is received and due to internet problem it does not return to our web page, how do I know that payment is received from a particular user?
If there is a network issue and PayPal cannot issue the IPN message, then according to their documentation, they will retry 15 times up to 4 days.
The IPN message service does not assume that your listener will receive all IPN messages. Because the Internet is not 100% reliable, IPNs can get lost or be delayed. To address these issues, the IPN message service includes a retry mechanism that re-sends a message at various intervals until your listener acknowledges receipt. An IPN message may be present up to four days after the original was sent. The maximum number of retries is 15.
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/
This item below might help. Instant Payment Notification should work, but in the case of a network failure, if the payment reached PayPal but the purchaser did not get back to your site to complete a purchase, then you should still receive an email from PayPal telling you that you have received a payment.
using paypal button - can my webpage tell if paypal transaction was successful or not?
You get a confirmation email with their name and email address - be aware that occasionally this may not be the user's current, most active email address. You can also log in to your PayPal dashboard to see all details as well, of course.
You can look up your payment details from the email and compare them to your own user records in your database. If the email they use for PayPal is not the same as the one they registered on your site with, you can still look up their name from the email - in practice it seems to happen extremely rarely that payments have such a problem in my personal experience
I set up a script which emails my users with a passcode to get to the online product they bought which is emailed to them so they can submit that later along with their email address. This is the first thing that happens on return to my script so at least if the site fails to respond properly they can get to what they bought later.
The script uses PHPMailer and cc's me with their passcode so I have it available to re-send to them if they write with a complaint. It doesn't help if the PayPal return for Instant Payment Notification fails completely but the other answers cover that very fully and detail the PayPal repeat attempt process well.
Instant Payment Notification scripts can be downloaded from PayPal for modification by yourself as per the article linked to above.
To be perfectly honest, this is one of PayPal Standard's largest holes. IPN is a POST callback (as is PDT) and they check to make sure they get a 200 response or else they retry (and you can use the IPN history in your PayPal account to resend missing IPNs). But this method still relies on you getting the callback in a timely manner and it's not foolproof. Worse, you need to verify the IPN call and that introduces yet another point of failure in calling PayPal to make sure they did indeed send you the IPN you got.
There's a couple of ways to deal with this
Audit your account regularly. This is a good idea in general, but for a small website this shouldn't be terribly hard. Match your invoices up to your PayPal payments. Obviously this doesn't scale well so...
Switch to Payments Pro. There's more hurdles to this (like more PCI compliance, SSL certificate, etc) but the major advantage is that the API is far less susceptible to the whims of the Internet and only involves one call for credit cards (you can ignore the IPN because the API tells you everything you need to know). The worst that can happen is you send a payment API call and fail to get a response. This is exceptionally rare as PayPal makes sure their API is 99.9% reliable (IPN relies on your server being reliable). Speaking from experience, Payments Pro has far fewer issues than IPN does.
In your application, you should have a status field for orders. If you haven't received the ipn, you wouldn't change the status to Paid.
After that, if you receive an email from Paypal that someone has paid, check the order number, and change the status manually.
how do I know that payment is received from a particular user?
Paypal will send an email both user and you.
Paypal offers 2 solutions for your problem.
PayPal IPN - it notifies the server with a POST request to a specific URL, whena transaction has been successful, declined, aborted by user and so on. Paypal provide an IPN Simulator (the worst simulator ever) in order to test its functionality. you may give it a try at : https://developer.paypal.com/developer/ipnSimulator/
Paypal WebHooks - The webhooks are the "New Kid in the Block",they are basically "user-defined HTTP callbacks that receive events for the subscribed event types. Webhooks are asynchronous, the order is not guaranteed, and idempotency may lead to the same event being sent more than once." as stated in the Paypal documentation.
You can read more about it on : https://developer.paypal.com/docs/integration/direct/rest-webhooks-overview/
For any further help, comment below and I shall try to help.
Cheers,
You have to use notify_url for this purpose
<input type="hidden" name="notify_url" value="https://domain-name.com/ipn.php">
I want to integrate my application with Authorize and I need to get the transaction ID to save this information in database. The question is, can I do this with SIM? I know you can set a URL to get back to you homepage, but is it possible to send the transaction ID back to homepage?
You have two options:
Relay Response
Relay Response is a feature available to merchants using Server Integration Method (SIM) or Simple Checkout. It instructs the payment gateway to return transaction results to the merchant using an HTML form POST to a specified URL on the merchant's Web server. A script or program at the URL can be used to create a custom receipt page using the transaction information. The custom receipt page is then relayed back to the customer's browser. Relay Response does not redirect the end user back to the merchant’s server, but relays the page content to the end user instead of displaying the Authorize.Net default receipt page.
Silent Post
This feature allows you to specify a URL, or Web address, to which the payment gateway should copy the transaction response that is sent to the configured Relay Response URL. If you are not using Relay Response, the feature allows you to specify an additional URL to which transaction responses can be posted.
If you're looking for sample PHP code I wrote an article that includes that here.
My recommendation is to use Relay Response as it gives you an opportunity to customize the receipt page your user's see. (Although you can use both as they do not conflict with each other).
(I am the author of both Silent Post articles)
When the customer selcts Visa/Mastercard as the payment method, they're sent to an external payment terminal to make the actual payment (NETS BBS). After inputting their card data they're then sent to an authorization terminal (3D Secure), if their bank supports it, to verify their payment. At the end they're sent back and is presented with a "Thank you" page. And this is where the google ecommerce tracker is executed.
But what happens is that "mpi1.3dsecure.no" gets detected as the referral. This is the authorization terminal where the customer verified their payment. This is to some degree correct since it's where they entered the "Thank you" page from, but is not what we're looking for. We want to know where the customer came from into the site to begin with.
Has anyone wxperienced this behaviour, and know of a workaround to this?
Tried to put the google code before being sent to the external payment site, but that can provide unaccurate results since not all payment succeeds...
Go to the property settings and add your payment gateway to the referral exclusion list (won't change data already recorded but should fix the problem for future transactions).
so I got a guy to code this IPN feature for my website.
Basically a user pays thought the main site then it forwards the ipn stuff to another server and that server sends ipn payment to paypal. For some reason it keeps saying "retrying" under the paypal IPN history. Is paypal blocking this and does the payment have to be made from the same server? Thanks hopefully this makes sense!
IPN does not happen until after any transaction has occurred, so what you're saying here doesn't really make sense. There's no way IPN would be sending any payment to PayPal. PayPal simply POSTs transaction data to your IPN URL after the transaction has taken place.
That said, if you're seeing "retrying" in your IPN History that means your IPN script is not completing successfully, and as such, is not returning a 200 result code back to PayPal's server. You need to troubleshoot your IPN script to figure out what's failing and get it fixed.
Your web server logs should provide the information you need. If you look there you should see a log of when your IPN URL was hit and it should also provide the result including any errors that were generated from the request to that script.
I like to create a simple HTML form with the action set to my IPN URL and then include hidden fields that match the fields/values that I would expect to get from IPN. This way you can load that in a browser and submit it directly so that you can see the result on screen which can help with troubleshooting and debugging.
Keep in mind that when testing that way, though, the data is not coming from PayPal's servers, so it will not verify. You'll need to make sure your script is setup to handle this accordingly for testing purposes.
I am having some problem regarding Paypal IPN not getting fired on one of my server. Below is the scenario.
1) I have two sites site A(old) is on server X and site B(new) on server Y.Both the sites having identical Paypal express checkout form submission and IPN code.
2) Site A is running smoothly with paypal express checkout form submission and IPN is get fired correctly.
3) But with Site B, though our form gets submitted correctly and payment is successful, IPN is not getting fired.
More information :
I checked Paypal`s business A/c for any of functionality that may needed to add IP/domain where IPN is located.
I have also checked with Paypal support where they says that from 25 March 2014 they have told to add Paypal`s API related IP address to our servers firewalls. We had done with adding those IP address but still this is not working.
URL : https://ppmts.custhelp.com/app/answers/detail/a_id/14/related/1/session/L2F2LzEvdGltZS8xNDAxMTcyODkwL3NpZC9VbENEUWhWbA%3D%3D
Hope following information is sufficient for you. Please suggest if any one of us have some solution to overcome.
Thanks in advance.
Unfortunately, there's not much issue specific information for me to work with, so lets make this an IPN Troubleshooting Guide for future reference :)
Check the IPN feature status for the given account -
https://www.paypal.com/cgi-bin/customerprofileweb?cmd=_profile-ipn-notify (login to your account first, then follow the link to be taken to the IPN Settings)
Alternative:
Login to PayPal.com
Open Profile --> My Selling Preferences
Find the "Instant payment notifications" option
There are four states IPN can be in:
Enabled --> If you're prompted to choose your settings, IPN is
enabled and IPNs will be sent if a notify URL is passed in the
checkout request.
Enabled with Default URL Set --> If a "Notification URL" is displayed and "Message delivery" is set to enabled, the default URL will be used every time you do not specify a different IPN URL in the checkout request (e.g. eBay transactions will be sent to the default URL because eBay's Express Checkout Integration does not pass a notify URL)
Disabled --> You never set the default URL, but IPN URL passed in your transactions has been throwing too many errors. You should see the empty Address field and the option "Do not receive IPN messages (Disabled)" being checked.
Disabled with Default URL Set --> a default IPN URL was configured at some point in time, but due to failures on the default URL or on the dynamic URLs, the IPN feature has been disabled. You will see the URL and "Message Delivery = Disabled"
Why does PayPal disable IPN delivery?
PayPal expects your server to respond with a HTTP-200 OK message. If we receive a different response code, a retry mechanism is set in motion.
The IPN message is sent a total of 16 times with increasing time frames between each attempt. If the errors for one URL reach a certain threshold, IPN is disabled automatically. You will receive an e-mail message to the main e-mail address listed on the PayPal Account, that warns you of an impending deactivation
If IPN is enabled, check the status of the last IPN messages under https://www.paypal.com/cgi-bin/webscr?cmd=%5fdisplay%2dipns%2dhistory&nav=0%2e3%2e4
It'll show you the last HTTP Response Codes your server is sending back and you can filter for failed / retrying messages.
Check http://en.wikipedia.org/wiki/List_of_HTTP_status_codes to see what the status means.
If there is not HTTP Response code, there's a connection issue on a lower level.
Most frequently caused by:
Firewalls
SSL Connectivity Problems (try using HTTP)
Black Hole Routing
If you feel that everything is configured correctly, check out https://ppmts.custhelp.com/app/answers/detail/a_id/733
If the IPN messages are marked as "SENT" (HTTP 200 Received), the next step in IPN processing is posting the data back to PayPal for validation. You can either enable logging within the script (dump the HTTP request and response in a file on the server) - or you can contact PayPal MTS ( https://www.paypal.com/mts ) and ask what's visible on the PayPal Side.
A good test to check the connectivity to paypal is to run the following command on the webserver itself:
curl -d "cmd=_notify-validate" -v https://www.paypal.com/cgi-bin/webscr
If you see that the POST has reached PayPal, but PayPal responds with INVALID for all messages:
Check your code, https://github.com/paypal/ipn-code-samples is a good source of samples
If PayPal responds with INVALID to some messages, you're likely running into an encoding issue. You'd best set your Character Encoding settings under https://www.paypal.com/cgi-bin/customerprofileweb?cmd=_profile-language-encoding - set them to UTF8 for the best results.
If PayPal Responds with VERIFIED, but your script doesn't continue processing after validating the payment, make sure you run a TRIM() (or the equivalents in the language being used) to remove whitespace, line feeds and CRLF
What happens afterwards is up to the IPN script you may run into errors while connecting to a database, parsing the IPN message for certain data or some coding errors.
In short: If the IPN message has been received, posted back and verified, everything else happens in your own code on your server and you'd have to start digging through log files (or make sure logs are being created, that's always a good idea) to find out what's going on. If the problem is reproducible, it is always a good idea to check what happens with one of the sample scripts (which include logging)
Hope this helps tackling IPN issues head on - any questions regarding IPN? Contact paypal.com/mts if you want to investigate what's happening on the paypal side.