Quick other question. In your opinion, what is the best way to write the information from the temporary custom form to my installation sheet?
- with APIs through Make once the transaction has been approved by payhere?
-through the button on the hidden tab that will show up once Make confirms the payment has been approved.
There are a lot of variables to pass through, so I would prefer the button. But Iām sure Iām not thinking of certain scenarios where the link could break and I have an approval, but nothing was written.
So I assume you have a few custom form pieces of info you want to write into the same row as the payment confirmation row from PayHere?
What I think you can do is passing them as custom variables for the payment link, and then once the payment is made, PayHere will send them over alongside your payment info.
So in your case it would be something like custom_field_timeframe, custom_field_sign_width etc.
1 Like
The thing is I have close to 40 variables that have to be placed into a new row, so I donāt think it will be very efficient to feed them all through payhere? I was going to write a few things into payhere that identify the transactions and the user, but that was it.
In my head I was thinking(keep in mind I have never used Make):
- -I feed the the RowID, installation ID and other things like price through āconstruct URLā to payhere like you mentioned.
- -If there is a successful payment:
-
The payment status of āsuccessā or whatever it is gets written to my temporary custom form
-
Make takes the RowID of my custom form and creates a new row in my installations table with the info from the custom form.
-
I change the variable that hides the web view for the payhere checkout and shows the button that says āreturn homeā or āorder completeā. this button will clear my custom form as well as hide this tab and show regular tabs.
I guess from watching @Robert_Petitto 's video on glide API with calendly, I am also unsure if Make can even āgetā information from a row, without that row being stored in the data store first. The only APIs are āadd rowā āset columnsā ādelete rowā. In this case it might work because I will be writing the āsuccessā to temporary row, which will give me access to store that row ID in the data store.
The method above makes sure that if there is a payment, an order is created. If I instead use the āsuccessā status to unhide a button that does all that set row column stuff, it is likely that 90% of the time everything will be ok, but it does not guarantee that an order is created. If the client closes out of the app when they see the āgo homeā or ācomplete orderā button because they see the payment success notification from Payhere, the order will be in limbo.
I rather not leave things to luck. I donāt think the above is a fringe case. What if the email notification for a successful payment comes in as a notification on the phone right as the client needs to click the complete order button. They might click the notification, which exits them into their email app and then they get distracted and donāt come back to the app for a while.
hope that makes sense. I think I overthink things, but the reality is if I have a whole bunch of these fringe scenarios, then they are more likely to happen.
1 Like
Robert but why arenāt you using Stripe directly but go through Payhere? There must be a reason somewhere I just donāt know it!
Payhere lets me embed a payment link directly using a web embed component.
Stripe links canāt be embedded, so users would be taken outside the app to remit payment and then somehow need to find their way back.
4 Likes