11
wtravel
Re: Orders/Payments module

Kaotik,
Thanks for your reply. I will have a peek at your module this weekend

Martijn

12
MadFish
Re: Orders/Payments module
  • 2005/4/28 14:57

  • MadFish

  • Friend of XOOPS

  • Posts: 1056

  • Since: 2003/9/27


I'd love to see a module like this, it is one of the remaining 'gaps'.

One issue with PayPal is that it can be difficult for operators not based in the US to use - they won't allow funds to be withdrawn to banks in many countries (eg. Thailand !). If it could support a range of payment services (or at least be designed to be expandable later on) would be great.

13
wtravel
Re: Orders/Payments module

Yes, that is the idea . Is there a best alternative for paypal in Thailand?

14
gtop00
Re: Orders/Payments module
  • 2005/4/28 16:03

  • gtop00

  • Friend of XOOPS

  • Posts: 498

  • Since: 2004/11/13


Quote:

wtravel wrote:
Yes, that would be the idea. The module should basically handle:

- Products and offers management
- Payment transactions
- Gateway management
- Reporting on orders/payments/products

Martijn


An additional request:
Could be possible to handle subscriptions too, (monthly or yearly) sending notifications on expiration to both sides?

15
davidl2
Re: Orders/Payments module
  • 2005/4/28 16:07

  • davidl2

  • XOOPS is my life!

  • Posts: 4843

  • Since: 2003/5/26


Option to change usergroup status upon successful transaction?

16
gtop00
Re: Orders/Payments module
  • 2005/4/28 16:09

  • gtop00

  • Friend of XOOPS

  • Posts: 498

  • Since: 2004/11/13


Quote:

Mithrandir wrote:
- Customers?
- Users? (log in and save having to re-type the same information)


Recommendation:

Registered users; should have an auto fill in feature
Customers; manual fill in (it is not necessary to register everybody, but keeping their non confidential data would be nice for later marketing use!)

17
Mithrandir
Re: Orders/Payments module

Quote:
Could be possible to handle subscriptions too, (monthly or yearly) sending notifications on expiration to both sides?

I have been thinking about that as well - but the whole point is to keep the payment process and customer separate from the product/service that is bought.

If done well, I imagine this to-be module would be able to work with another module so that the other module defines the product/service as a subscription (auto-assign to group on payment or whatever) while this module would only take care of the payment.

It would make this module suitable for a physical goods shop, a service provider, an automated music/download shop or a subscription service. But each of the mentioned ways would not need a module that incorporates music/downloads, services, subscriptions and physical goods AND the payment gateway - and individual modules for subscriptions, physical goods or music/downloads would not need to have the payment gateway in itself, only integrate with this payment module.

18
gtop00
Re: Orders/Payments module
  • 2005/4/28 16:20

  • gtop00

  • Friend of XOOPS

  • Posts: 498

  • Since: 2004/11/13


Quote:

Mithrandir wrote:

If done well, I imagine this to-be module would be able to work with another module so that the other module defines the product/service as a subscription (auto-assign to group on payment or whatever) while this module would only take care of the payment.


I agree as long as this to-be module WILL BE able to communicate with other modules handling goods or services or memberships.

19
Mithrandir
Re: Orders/Payments module

That's the whole idea. As I see it at least. This payment gateway module will not hold any information as to what is paid for, but only deal with who is paying and how much.

20
gtop00
Re: Orders/Payments module
  • 2005/4/28 16:41

  • gtop00

  • Friend of XOOPS

  • Posts: 498

  • Since: 2004/11/13


Quote:

This payment gateway module will not hold any information as to what is paid for, but only deal with who is paying and how much.


A small attention is also needed here. There must be a linkage between the amount paid and the reason for the payment, for taxation reasons. If we want to use XOOPS as a professional tool, we also have to consider the tax legislation.

I am very sorry for these may-be obvious suggestions, but it will be a pity to forget them.

Login

Who's Online

201 user(s) are online (140 user(s) are browsing Support Forums)


Members: 0


Guests: 201


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: May 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits