What we recently did (so far only in respect of membership renewals - which is really all that we were invoicing from WA) was to totally disable this in WA. We made the membership level free and with no renewal period.

Then we set up an account with the Wave App (free) although it may not support invoicing in South East Asia - but you could probably use the same concept with your payment service.

Next step was on our scheduled invoicing date to use Integromat to extract the applicable details from WA for the members who needed to be invoiced and for each of these load them as a 'customer' in Wave and then generate the invoice for the applicable amount. Now the total invoicing process is handled in Wave including the tracking of outstanding payments and follow ups.

The other advantage of this process is that it also positions us for multi chapter support on our WA site as with this concept we can direct the invoices for different chapters to different Wave instances (each instance is associated with it's own bank account) and also allows for multiple currencies.

While Omise may not be supported by Integromat if you have already developed the API calls to Omise for invoicing etc, you could easily enough port those to Integromat and call the API from there.

Future steps will be to develop options to handle Event billing and also Shop sales and Donations.

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.

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.

Did you get anywhere with this?