I'm new to webhooks and am not really getting the hang of some points of it. KISS; the current problem is, think about:
a platform
that provides a service X
to book a service X, customer Y has to pay in advance
every payment is authorized first only
every payment is captured after the service has been received
From the booking of a service to the capture of the related payment, only the authorization is handled involving the client-side. All the rest is handled on the server-side.
For every possible case of a booking of a service on my platform, payment authorizations is requested as the first action on the server-side. Adaptations of the DB of the platform are only executed after a successful authorization of the payment from the frontend.
The only fallback webhook I implement is for the case where a customer books a service, authenticates, and then loses connection. Because in this case, the customer would have booked the service, but the platform server could not make the related updates. So the customer will have paid, but not receive his / her service via the platform.
My strategy is thus to implement a webhook to listen for the event of a transaction authorization "completed", and, if no transaction data is found internally, execute what needs to be done.
BUT, two questions popped up:
A) How can I control that a webhook gets executed AFTER the regular server-side script should have been executed? Delay the execution of the webhook script? What are the best pracs here?
B) If A) is possible, isn't it smarter to just cancel the authorized payment in the webhook, instead of coding the completion of every possible transaction via webhook? Already the thing that you lose the entire payload in case of a client who lost connection (the payload that you need to execute the server-side tasks after a payment authorization), and the consequent need of passing the according payload back-and-fourth to your payment API, while ensuring that CID is encrypted etc.; this just sounds like overkill to me.. Was anyone in the same situation, and also decided to just immediately cancel the just-authorized payment in lost connections via webhooks? Or must webhooks generally execute the exact same server-side script that the related server-validation would do? Meaning I have to find a way to pass the payload to my webhook function?
The webhook is your notification that the event has happened - you're under no obligation to perform any processing right that moment, or ever.
If you're using webhooks as a backup to a primary synchronous flow (a good design!), then you can record the event and enqueue for later.
Stick a record somewhere indicating "got this authorization. Check this again in an hour to make sure the customer did the thing."
And to your comment above: you probably don't want your sync and async flows to be the same. Your async backup might involve contacting the customer eg via email, while that's not necessary for the sync flow since the customer is still on session.
Related
I am trying to integrate the PayPal REST API into my Symfony 2 web app but I find hard to understand how exactly the complete workflow looks like:
The PayPal docs describe the following steps to accept a payment. One can use the PayPal Playground to simulate these steps:
Get an access token
Create a Payment object by querying the API
Redirect the user to the approval url received in the Payment response
After the user approved the payment on the PayPal page, he is redirected back to my page, using the success-link defined in the Payment object. Use the received information to execute the payment.
Payment is completed with status approved
From the docs: Once a payment is complete, it is referred to as a
sale. You can then look up the sale and refund it.
So far so good. BUT: Where are Webhooks used/fired in this workflow? I have defined a wildcard Webhook (accepting all possible events) in the PayPal Developer Dashboard.
My observation is, that my system receives the Webhook event 1-2 Minutes (!) after the user was redirected back to the success-link and after the payment was executed (Step 4).
Beside this long delay between executing the payment and receiving the Webhook, this workflow means, that I only receive the Webhook AFTER handling the success-link. This means, handling the success-link is absolutly necessary for the payment to be completed. Is this correct?
Do I need to use Webhooks?
I already asked this question a few days before and the answer by nifr is quite reasonable: One cannot trust the user to follow any redirect URL but should only rely on the Webhook events.
However this collides with the observations I described before, since I will never receive the Webhook without handling the redirect URL...
So, handling the PAYMENT.SALE.COMPLETED webhook event does not make a lot of sense, since this should already be done in when handling the redirect URL. Correct?
However, to handle updates on pending payments, handle refunds or reversed payments, etc. are only possible by listening on those events.
So the answer is: Only use Webhooks to get updates on payments made before. Correct?
So, the main questions are:
The 5-step process to accept payments does not say anything about using Webhooks. This does not seem to make a lot of sense, because without Webhooks one would miss update events, etc.? So, is it really possible to implement the complete payment workflow without Webhooks?
If yes, how are updates (refunds, pending, etc) handled in this case?
If no, what is the right strategy/time to fulfill the order since it take quite a long time to completly receive and handle the webhook?
i am still a newbie in PayPal world, but few days ago i integrated PayPal Plus REST API in an online Shop, and from my understanding i can tell that the workflow looks like:
create a Payment
redirect to PayPal
Payer could pay using PayPal account OR (using Bank Direct debit or Credit Card Payment without PayPal Account)
After completing the process on PayPal side, PayPal redirect the user back to your success URL.
till now the user is still not charged(you got no money). At the moment where you (in your success URL) do $payment->execute($paymentExecution,$api); , you ask Paypal to charge the amount from user. BUT also after this, you got no Money. Paypal have first to process the charging and notify you later via WebhookEvents.
the Webhook Notification (with that nasty delay) is especially important when the user pays per direct debit or Credit Card etc. Processing such Payments takes few seconds/minutes.
the redirectUrl ist absolutly necessary for charging/executing the Payment.
here on execution succeed, just to tell the user, that he finished his Job, and you can here save/capture the PaymentID/Transaction id for later usage/update via WebhookEvent Listener.
so i would recommend you to update your Database(Payment completed) only after receiving notofications via WebhookEvent Listener and not in the success RedirectUrl.
In PHP, when handling the postback from Google Wallet confirming a purchase, it's possible that the server will not reply within the ten second time limit--this is sometimes completely undetectable serverside.
What should I do to prevent this? Is there a way to confirm the purchase was successful?
Google Wallet for Digital Goods will fail for both you (merchant) and the user/buyer if you don't respond to the postback as required.
Important: If you specify a postback URL, your server must respond promptly and correctly to the HTTP POST messages that Google sends for each transaction. Otherwise, the transaction will be canceled.
REF: https://developers.google.com/commerce/wallet/digital/docs/postback
If you're saying your system may think the trnx is "good" and it just took time to respond (at which point Google already canceled) - there is a "verification step" that occurs on successful transactions - success handler. You can use that to "confirm" the order on your end. So if Google canceled the transaction, your system will not get this final (re)confirmation (because your success handler will not be called).
I guess you could also use the failure handler for this, though it won't have an "orderId"
Hth...
As a side note on the comments, Google Checkout was also renamed Wallet at some point. If memory serves, it was really more for buyers than for merchants...so yes, do check on what API you are referring to.
This answer is specific to Wallet For Digital Goods (it is completely separate from Google Checkout/Wallet, which also included some support for digital purchases).
See this link announcement
I am implementing Google Wallet for Digital Goods in a website, using PHP and HTML/JavaScript.
Google will wait 10 seconds for the postback.php to respond with 200/ok and to output the order ID. If that has happened, it will charge the Credit Card and call the success_handler function. After 10 seconds of no response however it will cancel the transaction and trigger the failure_handler function.
I want to protect myself from my server being slow and only want to deliver the digital good if the success_handler has been called. To prevent fraud i need to verify if the order ID was correct (because the successhandler is client side).
How do I get the order ID of the transaction into the success_handler, so that I can verify it in my system and if all matches be sure that I received the money and deliver the digital good?
As you point out, to prevent fraud, you need to check with your server that the transaction calling the success handler matches a corresponding postback call made to your server.
You will need to match the order Ids returned by the two callbacks. The order Id is part of the jwt returned in the success handler or server postback (under "response"->"orderId"):
https://developers.google.com/commerce/wallet/digital/docs/jsreference#successhandler
We have an eCommerce site that is using Authorize.net as a payment gateway.
We have recently run into the issue of people submitting a payment confirmation, and then clicking submit again later on. This is resulting in a double-product situation, and/or double payment.
Some things to consider:
The payment confirmation page is a result of a PRG (Post-Redirect-Get) which is loaded before the user submits their payment
We have functionality in place that will actually act on each part of the request (see below for description of this)
This situation will only apply when Authorize.net transactions take longer than normal.
This is NOT in production yet, we are merely looking for a way to test this new functionality to prevent this behavior.
The Prevention Piece
We have a multi-step checkout form that follows the following process:
Product selection
Payment entry
Confirm Order / Submit Payment
Receipt
Each step of the process executes a call to a service that checks to see if the user has a current 'order' that has one of several statuses: started, processing or complete.
If the order is started, it will redirect them to the first page of the checkout flow.
If the order is processing, it will redirect them to a placeholder page that executes an ajax request every 2 seconds to check the status of the order. When the order is complete, they are redirected to the receipt page.
If the order is complete, they are redirected to the receipt page immediately.
The Problem
Since this functionality is really only valid when the processing transactions take a bit longer, it gives us problems testing it - for a few reasons:
Our dev server is slow, and it is more likely than not that Authorize.net will respond to our request before the page is even rendered by the application.
If we dummy the response up by using the PHP function sleep(), it blocks the thread and nothing runs, and we are in the same boat as [1].
What we hope
I do not know if there is a way to make Authorize.net respond to requests in a slower manner via some parameter, or if there is another way to accomplish this. I welcome ANY and ALL ideas!
You shouldn't be testing directly against Authnet for this. Make your own Authnet "server" and have it delay its response to you. For unit test I wrote for my Authnet library I created my own fake server which sends back the appropriate response I need to test. You can do the same and have the "server" wait as long as you need to before sending back a response. The response doesn't have to be real for you to test a delay.
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.