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
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
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 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.
I would like to know if this is possible to add new payment method for Bigcommerce. I tried to contact their support without any luck. If anyone is familiar with bigcommerce and know if this is possible, i would appreciate any advice.
I already read their API docs and didn't found anything useful - only method to obtain list of available payment methods.
I already tried to signup for their partner. Without any luck.
We've done this before for a couple stores to allow clients to process payments through their own processor. The way we achieved this, is essentially through the following high-level steps:
Allow payments by Check (or similar offline method). We are going to replace this with the custom processor.
You'll notice that if you attempt to checkout via Check, that BigCommerce automatically creates the order for you, but sets the order status to Awaiting Payment. Upon submission the user is automatically sent to a 'Thank You' Order Confirmation page that contains both the Order ID and some payment instructions (such as where to send the check to).
Here's the trick -- Modify this 'Order Thank You' page to prompt the user for her or his credit card information. A simple HTML form will suffice here, performing the actual request via JavaScript.
Once you have the user's credit card data, you can then POST it to your own external server, where you would connect to and send data to whichever processor you are using. Additionally, you should make sure to send the Order ID to this program, so that you can connect to the BigCommerce API to load billing information, and then subsequently adjust the order status to either approved or declined depending on the response from your processor. Finally, you should send back some sort of response to the client to inform of the result of the charge attempt.
That's pretty much it in a nutshell. The way you integrate with the payment processor (step 4) is unique to whichever processor you are using. I hope this makes sense.
Although opinion based, I'm a huge fan of serverless technologies, and would suggest looking into AWS Lambda + AWS API Gateway. The benefit here is that you don't need to worry about creating an infrastructure or the associated concerns of security and scale. Rather, AWS Lambda allows you to simply upload your software, and allows it to be executed via an HTTP request to some defined endpoint set through the API Gateway. Lambda will scale automatically for you, and you don't need to worry about system level security concerns - only security at the application level. It's truly a set and forget setup, and a bleeding edge technology. Not to mention dirt cheap!
Implementing a new payment method is unsupported and requires hacky workarounds since we implement payment gateways via the core app. You can do this on blueprint by using an offline payment method and then using the API to update payment statuses, etc. I'd recommend using ActiveMerchant if you do wish to go down this path.