i have a backend system using PHP to handle transaction.
in this case, there is three environment involved.
A = client, B = my system, C = payment gateway
the scenario is :
client (A) send request over HTTP post request,then
my system (B) receive that request and then
send request to payment gateway (C) using cUrl.
what happen now is :
every request from client proceed by my system partially, which mean next process will be process when previous request to C has response.
what i want is :
even the prevoius request not yet responded by C, my system can receive next request from A and send another request to C.
Related
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.
Stripe documentation points out that:
Because properly acknowledging receipt of the webhook
notification is so important, your endpoint should return
a 2xx HTTP status code prior to any complex logic could
cause a timeout.
In the web hook I'm developing with PHP this is exactly the
case — there is some complex logic involved after the event
is received.
Currently I'm returning the response code with a simple call
to http_response_code(). But how can I send the response
headers (with the code) before proceeding? Would a flush()
call force the headers to be sent?
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)
I'm attempting to use the iron.mq push queue, but am having difficulty figuring out how to properly respond to the queue after receiving a message. I realize that I might also not fully understand how the queue system behaves, but my understanding is that it is something like this:
Message sent to queue
Message pushed from queue to my endpoint
Message is 'reserved' until my endpoint responds or times out
Endpoint responds with either a 2xx (success) and it is deleted or 4xx/5xx failure, in which case the queue will attempt to resend the message to the endpoint.
For example, my script (using FuelPHP) has something like this:
$headers = Input::headers(); //gets array of headers sent from ironmq
$data = #file_get_contents('php://input'); //get the body
Now that I have received the message, I want to do one of two things:
Process message and return response to ironmq servers that it was successful
Delay the process (by sending a 4xx/5xx?) and have it be resent after a defined period of time.
But... how do you respond to a push message? Using the PHP SDK's deleteMessage method causes an exception as the message appears to no longer exist.
Version 1. Endpoint responded with status 202. http://dev.iron.io/mq/reference/push_queues/#how_the_endpoint_should_handle_push_messages
You should explicitly delete a message after processing via deleteMessagePushStatus()
Version 2. Endpoint responded with status 200. Message will be deleted automatically, no actions required
so - two ways:
202 -> do long work -> deleteMessagePushStatus()
4xx or 5xx -> 4xx or 5xx (many times) -> 200
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.