hi folks,
I was testing to see if i could get a connection with Payhere/Make/Glide.
-The payhere checkout is inside a webview on a tab that only shows up during checkout.
-If a payment is successful then the glide api changes a column value so that the webview now becomes hidden and a payment success/button shows up. I need users to click this button to clear the custom form and hide the tab.
Currently the Make scenario is quite simple as i am just trying to see if i can make a connection: if payment is successful, change a column value to a number. This number triggers the visibility.
I was hoping that the api would be fast enough to hide the webview before the Payhere’s “payment successful” page showed up as that would look glitchy and confusing to see a confirmation page suddenly vanish to another confirmation page. But it was worse than that. It took 14 seconds for the visibility condition to change. That won’t work as the use can navigate off/click cancel, go to the email app when the email comes in etc.
is this normal behaviour? if so then this route won’t be an option.
Glide is Pro. I upgraded so that i could have access to APIs.
Make is the free plan but i think it should still be considered “instant” or whenever it is received.
What if you set the PayHere successful page to your app’s home page? When I read your comment the other day I thought it was a long con to have it set up like that, that simply won’t be fast enough to beat the PayHere redirect.
So I don’t believe that I can set the payhere successful page to my home screen. Maybe because it is the home screen? I know that we can do so for deeplinked pages. In this case it says it cannot embed itself. I would still have the issue as I explain in the video below where the “edit/cancel” button would still show up above the web embedd.
What is puzzling is that I was watched @Robert_Petitto 's video on Glide APIs, and when he clicks the calendly create new event button, the new row is added into glide in just under 6 seconds.
Good news:
I wanted to know if the “create row” api fired faster than the change column api. Looks like it does. I was able to get it down to about 4-5 seconds. It’s way better, but still worrisome as the “back/edit” button is still visible. Maybe it just feels like an eternity to me as i know what is actually going on on the page. The customer might not notice, but i think it is too risky to run it that way.
I did it by having glide create a row with one variable (the userid being pushed through payhere as a custom field). I then made a relation to it from my other sheet. I set the visibility of my checkout page elements to whether or not this relation was empty or not. My plan is to delete that row once the user finishes the transaction.
The bad news:
I tried it once more right after, and something very strange happened. It took 18 seconds AND 5 new rows were created. Make had 5 instances of the zap, all with the same transaction information. So somehow the webook was triggered 5 times. Payhere only had that one transaction when i checked (which makes sense because all the webooks had the same info). I tried a third time and everything worked ok.
Ah that sucks. Seems like PayHere tried to have a webview of the page, which wouldn’t work due to security reasons, instead of navigating straight to that page, which was what I assumed.
So I assume the whole reason you don’t want to use just the webview (not the other buttons you have on there) is because you fear the edge cases that the user clicks the “done” button before they actually pay?
Does it matter to you that the order is done or not? Logically, I think when they accidentally click done they can always click your button to get in and actually pay. Then, the webhook fires and it should trigger some kind of visibility condition in your app to hide the payment button for that order.
That’s the way I usually build it. Do you have any concerns you want to share? I just want to understand more about why you have to do it like this, because it’s not the way I usually see it.
So it doesn’t matter if they hit done and go back before they pay. It’s once they pay that there is an issue.
I need for them to hit a button to write the custom form data to a new table and then clear the form.
So once they click pay and the order is processing, then they could accidentally hit done and start wandering the app. It’s only 5 seconds but it does feel extremely long when you are waiting for a confirmation. By hitting done they would be brought back to the order screen or the order review, which will make them think “huh? Did my order go through? I thought I just paid”. Then all of a sudden out of nowhere the visibility condition will kick in and they will be very confused.
If they don’t hit done at the top left and let the payhere confirmation screen come up, then they are now faced with two “done” buttons. The one in the web view and the one on the top left. So now they aren’t sure what to click, and then all of a sudden the visibility kicks in and they are at a new screen. It’s a bit all over the place.
That’s why I think doing it the tab way is a little better because they are less likely to hit “cancel order” if they have already paid. They might be inclined to click the “done” button in the other one. Also, opening the web view as a link will close it if the app crashes or the internet fails. The tab will always get pushed back to the user when they come back, forcing them to hit a button to get out of it.
It’s just those few seconds that are really killing me. The payhere confirmation goes pretty fast, so I’m not sure why everything else is taking so long. I tried removing the filter for the “only if success” in Make. I thought maybe if glide didn’t have to wait for a successful payment, but just any payment to start the writing of the table process, it would start as soon as a transaction was initiated, not when initiated then checked if successful. This would have brought them to “loading screen” or “holding area” till I could then check if successful or failed. But it did not help the timing.
I am losing hope. Browsed the “glidecartv2” thread and checked out the app. Even something well built like that has a 12 second wait time and a warning saying “please be patient and wait”. I just know customers… they don’t read. I always expect the worst.
I agree with this. Unfortunately the “Done” button in both sides are not things we can customize.
Considering what you said, I wonder if it’s better for you to use a Stripe Checkout process instead. Just take them out of the app and don’t have to worry about them accidentally clicking anywhere.
Once they pay in Stripe, it should take some seconds for the row to appear in Glide and hide the Stripe button, if you configure it correctly.
The whole thing here is on Make’s side. So PayHere receives the payment, initiates a webhook payload, then Make processes your flow and write a row back to Glide. Then it has to communicate to the device that a new row has appeared. In my experience, it would take at least 6 seconds, for some cases more than 10 seconds.
It used to be much worse pre-Glide API, I’m not sure if they can make it any faster.
I am unfortunately going to give up on getting payments prior to ordering. My only hope is if Glide overhauls the buy button.
I tried just bringing them out of the app and using stripe, but if they send it to someone to pay or do all kinds of different things, then it’ll just send a payment into nowhere.
Afterwards I tried a multitude of payhere alternatives. All were similar. I had some high hopes for one called “checkoutpage” but in the end the zap took even longer to fire. I thought because the loading of payment confirmation took 6-7 seconds, that the zap would fire and the visibility would trigger right as I got the confirmation. But it took another 10 seconds.
Tried zappier and integromat. Also tried paying for higher tiers so that there would be “high priority” when the zaps or scenes would come in. But that didn’t help. It may have shaved off like half a second for integromat.
I guess there has to be some give and take with no code. Nothing is perfect. I’ve already spent 3 days on it and need to get back to building. Hoping some updates from glide will allow for it down the road.
The buy button has had no love since its original introduction, I doubt there’s something on the way.
As I said in my previous comment, it would take some more time for the automation tool, whether it be Zapier or Make, to process your payload and push it back to Glide, then some more time for Glide to reflect it on the device, so ultimately it would always be later than you seeing the confirmation screen in the app itself, since it’s almost instant.
You can create a new payment link using the API, but there has to be a middle step to generate it before you show it to the end user. I think it’s risky to do it on the fly (e.g let the user fill in the details that you will use in the link, then have to show the payment page just seconds later on the screen).
