Is there a way for users to view their receipt upon purchase?

[jgramp]

I'm not sure if this is something that would sit within this plugin or elsewhere, but can users view their tax invoice/receipt upon purchase, or have this emailed to them perhaps for confirmation?

[rogiervandongen]

@jgramp This is not possible yet, but it is on the roadmap.
Please note that, to my very best knowledge, the core features (enrol_fee as well as the paypal gateway) do not provide a means for this either unless you look into your paypal account.

Having said this, it is on the roadmap, initially provided on a per plugin basis, but the goal is to be able to generate "grand overviews".

[jgramp]

@rogiervandongen - I think that's correct that the others don't have this option either.
That is great to know it is on the roadmap though.
Would it depend on the payment gateway plugin having this implemented, or can it be done from the moodle-availability_gwpayments itself?

[rogiervandongen]

@jgramp
I can't say too much about this yet because we're also still setting up possibilities and requirements, but it would be far from ideal to have the plugin itself handle receipts/e-mail notifications or perhaps even an invoice. Nor would it be ideal to have the core gateway plugin be made responsible (it may well be the wrong scope to initialise this from).
This makes sense if you consider the fact we also have the enrolment plugin and, not approved yet since it was marked as needing more work, the activity module.

Ideally, we wish to extend the "gateway payments" set with a (local) plugin that will be responsible for the receipts/invoices/email notifications. The implementation will require some form of callback mechanism, likely using a (class) component callback. A class component callback feature is also what drives the core payment gateways so it actually makes sense to us to complement the gateway payments set this way: it will delegate implementation to a single plugin so any repetitive code or functionality can be avoided. The added value of this approach,. much like enabling any plugin to make use of the payment gateways, is that any other plugin would be able to hook into this. This approach made the payment gateway feature very usable and it would be the same component callback approach that would make such a seperate plugin the best approach.

In the meantime, depending on how fast we can develop this seperate plugin, it might be a good idea to at least send a rather simple notification by email (or better: using the core messaging system).
We're trying to avoid implementing functionality we would more than likely phase out again in no time unless we can do it "quick and dirty". By quick and dirty, I mean something that can be written and implemented fast without too much effort.
If sending a notification using the messaging system would be sufficient, please let me know, so I can see what we can get done in the near future.

Can you share your roadmap or ideas in this?

[jgramp]

Hello @rogiervandongen,

That makes sense to make it a separate plugin.

We need to be able to generate a PDF tax invoice for users with the following 7 pieces of information (and an 8th - the buyer's name if over $1000): https://www.ato.gov.au/business/gst/tax-invoices/#SalesOf1000OrMore

1. the term "tax invoice"
2. the seller's identity
3. the seller's business/company number (in Australia this is the ABN)
4. the date the invoice was issued
5. a brief description of the items sold, including the quantity (if applicable) and the price
6. the GST/VAT amount (if any) payable – this can be shown separately or, if the GST amount is exactly one-eleventh of the total price, such as a statement which says 'Total price includes GST'
   6a. To be useful to others, there would need to be a way to define the term (GST/VAT etc), so the above text can include the correct term for that organisation's context.
   6b. Stripe allows you to add GST for Australian customers, so the total amount should already include this if using Stripe.
7. the extent to which each sale on the invoice is a taxable sale. If there's no GST owing (for non-Australians) then the 'Total price', should say this and not mention 'includes GST' (see 6).

Ideally an email would be sent, but if this was the default setting in the Moodle notification preferences and someone changed this, then I guess this would be ok, as long as the user can still retrieve the invoice somehow.

It would be great if at some point down the track such functionality could be incorporated into the core_payment subsystem, but given time restraints a plugin makes most sense right now.

One of our developers suggests:
" I would add a function to each service provider plugin (those are the plugins that provide a service in exchange of a payment. like enrol_fee, availability_gwpayments, or a hypothetical local_shoppingcart plugin) to return a list of items that should be printed on the invoice, In most of the cases, this list consists of only one item, and that is a record containing the description of the "thing" that is sold along with some other information like its price."

The name of the item would likely be the name of the activity (e.g. a certificate) on the course, or the course name itself.
E.g. 'Moodle Admin Basics certificate of completion'

[rogiervandongen]

Hello @jgramp

Thanks for your input so far, i have to wrap my head around it sooner or later (as there are many tax laws that can be applicable in various regions).

The suggestion made by one of your developers is actually exactly what's on our roadmap as far as extra needed information is concerned. Even the way of implementing it is our idea as well, but with the only difference it won't be part of the core payment gateway system: it will have it's own infrastructure and callback mechanism. It might ultimately end up in core, but for various reasons we've decided to use a separate component callback mechanism (we're developing some of these methods already although they're no public as of yet).

It might be a good idea, with your consent, to discuss some of feature requests by means of personal contact (e-mail).
This is to avoid long discussions here. If you're interested, just pass me an email (address is all over the source code ;))