Implementing my own payment gateway: is that possible?
I'm planning to implement my own payment gateway integration (to Omise, a kind of Stripe for South East Asia).
The plan is to make a "micro-service" that displays the payment page and then push payments to WA Payments Admin API.
Any red flags? Thanks
Hello, thanks for the feedback, I didn't realize emails where not sent with that method.
Regarding my implementation: since we are using the existing WA invoice & payment screens I ended up adding some Global JS that will look for PayPal payment buttons and replace them with a custom pay button.
The button will grab the invoice "document number" on the page and redirect to our payment page. It only works for screens that have that document number on it though, so the one in the profile/invoice section. Other payment buttons were changed to redirect to the profile section so user can click on pay there.
Our payment page is on WordPress (as the rest of the website) so we can leverage the WordPress SSO plugin to get the current WA user. From there we use the admin API and look for all the outstanding invoices for that customer searching for the document number (invoice id != document number).
Once we have the invoice we display it on the payment page, and we use a local payment gateway (similar to Stripe) to collect credit card payments (and to remember credit card info). Once it's paid we use the admin API again to record a payment for the invoice.
It does work but that's a lot of moving parts.
Fadi Rezq commented
Did this. One issue is that the Invoice Id macro is not available in several of the emails such as "Event Registration Pending" email and neither is the Event Registration Id macro so you can't get the invoice by querying the event registration id either. The invoice id is available in the Invoice email but we were not using those emails.
We ended up adding custom JS and HTML code on the invoice page. Unfortunately WA does not differentiate between Invoices, Refunds, etc so it's all "Financial Documents" to them and there is no macros on the Financial Documents template that easily gives you the invoice id or the type of financial document it is. We had to resort to parsing the page title using JS, to get the type of document, and the URL, for the invoice id. Very messy method.
A final issue is that receipt emails are not sent automatically once a payment is registered via the API. So we have to send them manually or use the SendEmail api operation (which looks like it's plain text). Another very messy solution.
WA should definitely take note of these points because some of them are very basic and surprising actually that they are not implemented. So that we can have a much cleaner more robust way of handling these situations.
Fadi Rezq commented
Did you get anywhere with this?