I would like to integrate my web application with the Square POS.
The goal would be to be notified each time a transaction (sale/refund/etc) is processed by Square for an account so that I can update inventory levels etc, ultimately so I can update inventory levels as transactions occur.
From what I can tell, it seems that the Square API's seem to be designed around my application initiating the transaction, then handing off to Square to process the payment. I simply want to be notified that a transaction has happened so that I can update inventory.
Is it possible to do this? Or is the Square API just for processing payments?
edit: After some more reading, I still haven't found a webhook to be notified, but it looks like I can ListTransactions, and RetrieveTransaction, so if I poll I should be ok.
You’re correct. Square’s API Webhooks will be what you’ll use to be notified each time a transaction is created or updated. We have a quick setup guide available in Square’s Developer Doc (https://docs.connect.squareup.com/api/connect/v1/?q=webhooks#setupwebhooks).
The PAYMENT_UPDATED webhook will alert you every time a payment is made, so that you can update your inventory.
Related
I am implementing the Stripe payment platform using JavaScript and the PHP SDK.
I don't have any issues with the implementation itself, but I am not sure whether I have to reuse an existing PaymentIntent or it's perfectly fine to have a bunch of them created and incomplete.
I searched for this in Stripe's documentation, but I can't seem to find anything related to this.
For example, in my test account I have this:
It's all for the same transaction, because I was changing some visuals and refreshing the browser.
I am aware that each PaymentIntent has an ID, but is it recommended to add it as a query parameter and retrieve it on refreshing, or is it better to always generate a new Payment Intent.
My main reasoning is to avoid having a huge collection of incomplete payment intents.
The default integration path for Stripe today is to create a PaymentIntent first so that you get a client_secret you can use client-side to render their UI via PaymentElement. This means that if your customers decide not to pay after all, you end up with an incomplete PaymentIntent which is expected.
This is not really a problem, other than appearing in the Payments list which can be confusing. You could also write a background job daily that would cancel any PaymentIntent via you know won't be completed because the customer left and you didn't have any data to contact them to upsell them for example but this isn't really needed.
Stripe also has a beta (docs) right now (Feb 2023) that changes the default integration path. This simplifies the experience because you can render the PaymentElement client-side with specific options such as amount and currency. You'd then only create the PaymentIntent at the end of the flow
when the customer is attempting to pay. That flow limits the number of incomplete PaymentIntents since you only create them when the customer really pays. You'd still get some, for example after a decline by the customer's bank though.
I am building an app to sell single item product (i.e, each kind of products listed on my platform only has a single item).
(this part has been done, and won't change) I built an in-house backend having the Rest API POST -D {"buyer_email": "abc#example.com"} url/items/{itemID}, let's call it transaction_call, which will make sure once a customer succeed the POST operation, his contact info is recorded into my backend as the successful buyer; and all other customers will fail to buy that item (at API level, transaction_call return 4xx error) because my platform can only sell one item for that product;
(this is the step that my current question is about) I am trying to use Stripe as my payment system on this platform.
I really want to integrate with Stripe as simple as possible (as I understand Stripe Checkout is the most simple / out-of-box way to implement payment). However, I am not sure if Stripe Checkout can achieve the above functionality correctly. Since the problem is a two-step problem, here is the potential issue I may run into:
Let's say, two customers A, B, get to my platform at 10:00am, both of them start purchasing process for a product, Item_a
If my system interact / call the Stripe Checkout first as the first step then call the transaction_call, here could be the problem:
A's Stripe call hits the Stripe server at 10:00:01am, and A's buying call hits my backend at 10:00:02am;
B's Stripe call hits the Stripe server at 10:00:01am, and A's buying call hits my backend at 10:00:03am;
in this way, we have already charged B but he really did not get the item
If my system calls the transaction_call first, and only if transaction call succeeds then it interacts / calls the Stripe Checkout, then
A's transaction_call succeed at 10:00:01am, but he for some reason decided not to pay (not click confirm button on the Stripe Checkout UI)
In this way, my system fails to sell the item to other buyers.
My question is whether the above reasoning process is correct, and whether I could somehow use Stripe Checkout to achieve what I am doing.
Maybe I have implement the payment functionality using Stripe Intent API to build a workflow-based payment, which I assume will be much more complex, if the Stripe Checkout way (simple wayO is really not possible.
From what I understand you have a potential race problem, where the item you're selling is very limited in quantity and you want to make sure that you can correctly notify users if it's out of stock or already spoken for.
For your first scenario, the simple solution is only invoke Stripe's API on your backend when you've received the transaction_call. For instance, you'd only create the Checkout Session once your system has identified that the item is still available. You'd then "lock" the item so that when B attempts to purchase you can immediately return an error instead of creating a payment via Stripe's API. The logic on who to charge (basically who initiated the checkout process first) in the case of a tie would then be for you to implement in your transaction_call rather than on Stripe's side.
The second scenario is a little tricker, as Checkout Sessions can't be cancelled once you create them. They automatically cancel themselves after 24 hours if no payment is made, but I doubt that you'd want B to have to wait that long if A abandons the payment flow.
Instead I think you should look at implementing a PaymentIntents integration, where you can more finely control the flow.
Your flow for scenario 2 could be:
A begins the checkout process, create a PaymentIntent on the backend, "lock" the item and start a timer
The timer (which you'd ideally show to your user) times out after N minutes if A doesn't pay
Cancel the PaymentIntent on your backend and remove the lock
B can now attempt to pay for the item, upon where you restart the process
We create PaymentIntents (with capture_method=manual in case that matters) in our iOS/Android apps when the user places an order.
We send the order to the connected venue once the charge.succeeded webhook fires. If this doesn't happen within a couple of minutes, we expired the placed order on our side.
So interestingly 2 out of 10 times we don't get this webhook to fire.
Im wondering if it's actually wise to listen to this webhook in order to decide if we send the order to the connected account's venue or not or if there is a better way to determine that the payment will actually work once we try to capture it.
Webhooks are the recommended way for getting a payment intent's status, but you can also use the API to get its status.
A quote from the Stripe docs:
It is technically possible to use polling instead of webhooks to
monitor for changes caused by asynchronous operations—repeatedly
retrieving a PaymentIntent so that you can check its status—but this
is markedly less reliable and may pose challenges if used at scale.
Stripe enforces rate limiting on API requests, so exercise caution
should you decide to use polling.
In your case, I'd recommend waiting for the webhook and then after a few minutes, call either the PaymentIntents API or the Charges API if you haven't received the webhook yet.
There's likely something else going on here, so I'd suggest you reach out to Stripe - webhooks should fire all the time, and it's a really really rare occurrence that they wouldn't.
The Square documentation for updating webhook events shows this URL format: PUT /v1/{location_id}/webhooks. However, creating a webhook event listener for every merchant location could be a lot of separate API requests, and it would be far easier to use the merchant_id instead of the location_id (even though this is not documented) and make one request for each merchant.
Attempting to do this actually works - when I PUT /v1/{merchant_id}/webhooks the webhook is saved in Square and transactions for any of that merchant's locations successfully send the webhook.
My question is, since this is undocumented (although it works) is it safe to rely on this approach?
While it may work currently, since it's undocumented, the behavior may change in the future and cause unintended side-effects. I strongly encourage you to follow the current documentation for subscribing to webhooks.
I have a business that uses the Square Stand and loves the functionality. They don't want to change anything about how they process orders.
However, they use CRM to do their email marketing and contact management. So they are currently manually inputting orders that are made from Square into their CRM.
What I would want to do for them is have them keep using their Square stand as usual, but on the back end have some script that gets called upon any time a successful order is made on their square stand, which will then use the CRM API to input the order automatically.
Is such a configuration possible? If not, what would be the workaround?
Square currently has a webhooks implementation that provides what you're asking for (notifications when a payment occurs). At present, it unfortunately does not include the full payment details, and so your script would need to call the payments API to obtain the full details when a payment occurs.
--da3mon