Certainly. There are rules as to what must be displayed/available to an online buyer so that he/she is never in doubt about what it is he/she is paying for.

My suggestion would be to make some sort of uniform standard for sending this information to the gateway module that could then display it, regardless of how this information came about.

Something like an array of "items" each with a "description", a "quantity" and a "price" that could then be subtotalled and totalled on the payment screen - without the gateway caring whether it is a subscription, a service, a download or a physical good that is purchased. It would need additional parameters to work with, anyway, as it would also need to know whether to capture the amount immediately or whether to only reserve the amount (as capture may not happen until the service/good is delivered - but in the case of a subscription, one should be able to consider delivery happening immediately)

A good point, though. Keep them coming - especially the ones mandatory by law.

Quote:

I have been in doubt about this one, but since I think that all of the modules that would use this also need to register the orders, you might as well include product/offer management in the transactions module.

By including product/offer management (tagged by module name) you can easily integrate a new shop module, a subscription module or advertisement module. The use of the functionality should of course not be mandatory. A developer could well enough only use the gateway functionality.

If product/offers management would not be included in this module and you would like to use a subscriptions module, an advertisement module and a shop module, all modules would need to have their own product/offers management. Therefor including it in the transactions module will have substantial benefits. I also think we could integrate invoicing functionality in this module for the same reason.

Your point about this module being only a transactions module I totally agree with. Handling after payment actions that are specific for each module should be done by the module actually handling the offered services.

Martijn

So, we are talking for a “Payments/Invoicing” module and not for “Orders/Payments” module.
The other/linked modules should handle orders and the Payments/Invoicing module should handle the payment AND the invoicing.

ANY other/linked module should provide the following data to the Payments/Invoicing module in order to be able to release an “invoice”:

- Item Nr/code
- Item description
- Item quantity
- Item final price (before or after any discount)
- VAT factor

- Seller’s official name
- Seller’s full address
- Seller’s VAT Nr.
- Seller’s profession

- Customer’s full name
- Customer’s address
- Customer’s VAT Nr.

The Payments module should provide the other/linked modules with the following data:

Payment total amount
Payment date
Payment way
Payment status (paid - not paid)

In short terms, we are talking about a good and professional tool for payments and invoicing, for any kind of good, LINKED to any good and professional commercial shop of any kind (real or virtual)!

George

I'd better expand on my idea so you can better understand my reasoning.

Let's take the downloads module as an example.
Today when you select download, you are sent the file. My idea is to instead send a request to the gateway module with information about the product (download title), price etc. in a standardised format, dictated by the gateway module. Then the gateway module would show this information and take care of payment. After correct payment details, the user is sent to a page in the downloads module (specified by the downloads module in the request) where the download would be initiated.

The gateway module does not have to know what it is the customer is buying, only some standardised information about the product/service and a location to send the user to after successful payment (and one for unsuccessful and one for if the user cancels the process). The information in the request would also be the basis for the invoice, which I agree should be handled by the gateway module.

That way, the downloads module content will BE the product catalogue and there is no need to have this in the gateway module as well.

A subscription module would be in-between the downloads module and the gateway module so that the downloads module sends the request to the subscription module, which checks the user's subscription status and if not valid, sends the user on to the gateway module, where payment will happen, then going back to the subscription module that updates the user's subscription status and sends the user on to the downloads module for actually downloading the file.

Any immediate errors in this thinking? Keep in mind that we are still at a very early stage and it will take some more thinking, analysis and design before settling on a solution.

Quote:
I'd rather say we are talking about a "Orders/Payments/Invoicing" module and not a "Products" module. The order information could just as well be in the gateway module since the payment will require full order details.
Quote:
Yeah, something like that
Quote:
I picture this set in the gateway module - otherwise each individual module will have to set this
Quote:
Also in the gateway module since it will be taken from the user's information specified in the payment process
Quote:
something like that
Quote:
Exactly!

Quote:

I have made use of a paypal payment module in PostNuke referred to here in this post

https://xoops.org/modules/newbb/viewtopic.php?topic_id=35087&forum=27&post_id=152212#forumpost152212

to which i had to add this also, I note that your module is also missing it

AUD - Australian Dollar Value

is missing. AUD is supported in paypal, please add it.