I have implemented the Mollie payment API for a simple App.
This app is used person to person. So the seller is standing next to the customer (physicaly).
The seller enters some data and then the App will display an iDeal QR code. The customer is supposed to scan that QR code and make the payment. In this scenario having a redirection after the payment is nonsense, but Mollie requires a redirectURL.
Anyone a suggestion how to satisfy both Mollie and me? Give Mollie an url but an url that does absolutely nothing.
I tried an empty html page on an url, but that still causes the customers phone to start the browser and point to a blank page.
Related
As far as I can understand the standard Invoice flow (https://developer.paypal.com/docs/classic/invoicing/IntroInvoiceAPI/), it's supposed that the user will pay the invoice following the link in the invoice email sent by Paypal, or by using a QR code printed somewhere.
It isn't actually possibile to retrieve the payment URL contained in the email or in the QR code directly via API, so the user can be immediately redirected to payment page?
At this time, you can manually build the payment URL with the following template:
https://www.paypal.com/invoice/payerView/details/<invoice_id>
There are other parameters that you can pass with the URL, but they don't seem to affect the ability of someone paying the invoice.
We're developing an application that uses Paypal Express Checkout, and we're finding that we get two different landing pages. We're actually finding a problem that seems superficially similar to Can you force PayPal Payments Standard API to show credit card fields first?, but with a few differences:
Everything is fine with the sandbox, and we get exactly the appearance (credit card first) we want.
On the live site, about 50% of the time we get exactly the appearance (credit card first) we want.
Sometimes, we get a more "mobile-like" landing page, with the credit card stuff totally hidden in a "Check out as a guest" button, as shown.
This feels like a failing A/B test to me. We're sending exactly the variables in the question linked above, and as I said, all works fine with the older landing pages. I know there are also cookie issues, but in this case, we're seeing it even when Paypal is not able to identify an account and when cookies are cleared.
Does anybody know if there is anything we can do to work around this?
I can add code if needed, but the problem appears to be more data than logic.
I had the same question after I started to see users coming in from the 'new style' page.
I found the answer here:
Paypal express "order summary" page
I added the "force_sa=true" parameter to my Paypal URL:
https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&force_sa=true&token=…
The new page is definitely weighted to appear more often on mobile devices. Without the parameter I get the new style page on a iPad after about 5 refreshes, with the parameter I can refresh as much as I like and never see the new page.
Obviously, PayPal will roll out the new page to everyone in the end, but this technique allows us a stop gap while we get ready for it ;-)
The screen pictured is PayPal's new checkout. It is only partially deployed at this point, you can think of it as A/B testing.
Regarding whether the customer sees "credit cards first", this mostly depends on whether they have a PayPal email stored in their browser cookie. If they do, the top "Log in to PayPal" section will be expanded, the email filled out, and they just need to type in their password and do about 3 clicks to complete the checkout..
If they do not have a PayPal email stored in their cookies, the bottom Create an Account or Pay as Guest section will be expanded. (If you want guest checkout, pass SOLUTIONTYPE=Sole in your initial SetExpressCheckout request).
The customer can always switch between the two expanded sections, it's just a "smart default" of sorts.
Try doing all your "credit cards first" testing in an incognito / private browsing window.
My understanding of the Paypal IPN mechanism is that my website should send over a message that includes:
a URL to go to if the USER completes the Paypal payment process
a URL to go to if the user hits CANCEL instead
a URL to go to once the payment has been checked for validity (after the user completes it).
But this doesn't makes sense.
I have an asp.net site.
I give the user a payment page. He enters how many widgets he wants to pay for.
Then it routes him to PayPal.
Lets say he completes all the steps to pay me.
So now he is sent to my website again, at the URL in #1, which tells him that the payment should be verified within 5 minutes.
But then, a few milliseconds later, according to my (probably wrong) understanding, he should be sent to the URL in #3. This URL is a blank page, since all it does is execute code that stores the successful invoice in a database.
When I actually try it, he is sent to URL #1, but there is no indication that he is sent to URL #3. No invoice is stored, no blank page appears either.
I am using the sandbox, not the real site. Also, all my pages are protected by a password, but that doesn't block URL #1 (since the user is logged in), so my guess is it should not block URL #3.
Any help is appreciated.
My understanding of the Paypal IPN mechanism is that my website should send over a message that includes:
a URL to go to if the USER completes the Paypal payment process
Correct.
a URL to go to if the user hits CANCEL instead
Correct.
a URL to go to once the payment has been checked for validity (after the user completes it).
Incorrect. That's a URL for PayPal to POST to, independently of the current browser session, when the payment is completed. That is your IPN handler.
But this doesn't makes sense.
Agreed. It isn't correct either.
When I actually try it, he is sent to URL #1, but there is no indication that he is sent to URL #3. No invoice is stored, no blank page appears either.
He isn't. PayPal tries to POST an IPN to that URL. You're supposed to have something listening there to process the transaction. There are further requirements of that IPN handler such as validation, duplicate handling, etc, which you need to familiarize yourself with.
I have implemented PayPal payments using PDT. I realize a combination of PDT and IPN is recommended, however for my purposes PDT is sufficient.
I am able to direct user to PayPal, collect payment and then conduct an action (updating account credits for the user in the database) when the user returns to my site. The URL shows an address like:
http://www.domain.com/process_pdt?tx=45138128VH922173V&st=Completed&amt=1.99&cc=USD&cm=&item_number=
So far so good. The problem I have is refreshing the browser with this URL causes the user's account to get credited again without redirecting the user to PayPal to collect payment a second time.
I have read that I should add the transaction id (tx in URL above) to the user table and check to ensure this tx id has not already been used. If it has, I should display an error message. Is this the only way to go about this, i.e. by storing each tx id in the user table and then checking for the id's existence each time the process_pdt URL above is called by the user (legitimately or fraudulently)?
Ah, yes: this is indeed the only way to go. As a simple sanity check you may want to do a redirect from the process page to a URL that does not include the txn_id (that way a casual refresh won't cause the problem, but if they use their back button it will still happen) but you must verify that the txn_id is only used once yourself.
I'm implementing a simple Buy Now button and I'm using IPN (not PDT) to verify the transaction.
A thing that bugs me is that I don't understand how come only after I set the notify_url field to the button I also get the transaction variables to the success URL, as GET params. It would seem normal to be the other way around.
Since the user could or could not choose to "return to the merchant's website" there's not way I should rely on that data. It does however seem to be identical to the one sent to the notify URL.
Some clarification would help. Thanks!
I know what you mean, after the user has finished paying and chooses to return to the sellers website (button in paypal page) they are redirected to your thankyou page.
I don't think it used to do this back in 2009 but now paypal will issue the redirect with all sorts of parameters in the url query string.
I'm just ignoring this information and relying on the backend IPN post which is verifiable by paypal
In my previous experience with IPN, I defined the location of the notify URL in the control panel. Once the payment is processed, PayPal sends a POST notification to this URL independent of any user behavior.
In any case, even if you define the notify_url parameter in the button, I believe PayPal will still send the payment notification seperate from the user behavior - they spawn a new process to send the data. As to why they are using a GET rather than a POST, that is odd behavior. However, in your IPN script you should still have logic that verifies the call with PayPal before you continue processing.