gnuherds-app-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to design such bank support? -- technical side


From: Davi Leal
Subject: Re: How to design such bank support? -- technical side
Date: Sat, 26 Jul 2008 13:22:49 +0200
User-agent: KMail/1.9.7

Antenore Gatta wrote:
> First a brief explanation of the terms:
>
> User:
>   Any GNU Herds registered user who is allowed to post job offer.
>
> Professional:
>   Any GNU Herds registered user who has filled the qualification form.

Payment service:
    Money transfers, being it actual money or e-money, and being it
    micro-donations or payments.
>
> Internet Merchant Account:
>   A Merchant Account is an account with a financial institution or bank,
>   which enables you to accept credit card payments from your clients.
>
> eWallets (PayPal):
>   Is an e-commerce business allowing payments and money transfers to be
>   made through the Internet.
>
> Electronic funds transfer (EFT):
>   * Cardholder-initiated transactions, where a cardholder makes use
>     of a payment card
>   * Direct deposit payroll payments for a business to its employees,
>     possibly via a payroll services company
>   * Direct debit payments from customer to business, where the
>     transaction is initiated by the business with customer permission
>   * Electronic bill payment in online banking, which may be
>     delivered by EFT or paper check
>   * Transactions involving stored value of electronic money,
>     possibly in a private currency
>   * Wire transfer via an international banking network (generally
>     carries a higher fee)
>   * Electronic Benefit Transfer
>
> This is already a Jungle...


> What we need is an easy (at least the most easy) way to allow payments
> and/or donation
>
> From a user point of view will be just an additional form, or
> additional fields in the existing ones, where it'll be possible to
> choose the available payments systems, the amount of money to transfer
> and eventually data needed by the payment gateway.
>
> This could be achieved in different ways, let's see which are the
> available payment systems from a - _non_ technical point of view.
>
> Take a look at the enclosed image.
>
> Almost all of the specified methods could feet our needs, but I'd
> rather focus more our attention on:
>
>   * Credit cards
>   * Payment Gateway
>   * e-Money

We could add the "GNU Herds virtual bank" feature as an option, getting so:
    * PayPal
    * CreditCard
    * GNU Herds virtual bank 

What do you think about?  Read below.


> Credit cards
> ============
>
> We have to act as PSP (Payment Service Provider).
>
> Accepting credit card payments through our web site actually requires
> multiple components. Between a paying customer, our bank account, and
> the Professional reciveing money three layers exist:
>
>   Web Site
>     Regardless of which merchant provider and gateway service you
>     choose, your web site will need to integrate with your service
>     providers.
>     Most providers include detailed web integration instructions.
>
>   Payment Gateway
>     This is the code that will transmit a customer's order to and
>     from an internet merchant account provider.
>     The payment gateway provides us the ability to accept customer
>     billing information and the necessary validation steps that
>     must be followed before the credit card is actually billed.
>
>   Internet Merchant Account
>     A Merchant Account is an account with a financial institution or
>     bank, which enables you to accept credit card payments from your
>     clients.
>     Unfortunately, most local banks do not provide internet merchant
>     account capability.
>
>
> How Much Does It Cost?
>
>   There are more merchant account providers than there are people
>   looking for internet merchant accounts
>
> Typical fees:
>
>   Up Front Application Fees
>     Some they require to cover initial expenses.
>
>   On Going Fixed Fee
>     Usually Montly fixed fee (statement fee). About $25 (some 10$)
>
>   Discount Rate
>     Between 2% and 4%. If the discount rate offered is 3%, and you
>     receive a sale over your web site for $20, you will owe 60
>     cents to your internet merchant provider.
>
>   Fixed Transaction Fee
>     Usually between $0.20 and $0.30
>
>   Termination Fees
>     A termination fee can apply if you cancel your merchant account
>     within a specified period of time (1 to 3 years)
>
>   Miscellaneous Fees
>     Example for a refund, between 10$ to 20$
>
> Example:
>
>   Montly Transaction  -  100
>   Transaction prize  -  10$
>   Average refund reuqests  -  5
>   Discount Rate  -  %2.5
>   Statement Fee  -  $10
>   Fixed Transaction Fee  -  $0.30
>   Chargeback Fee  -  $15
>
> Monthly Sales Revenue = 100 x $10 = $1000
>
>   Total Charges =
>       Statement Fee + Number of Transactions x
>         (Average Sale x Discount Rate + Fixed Transaction Fee) +
>       (Number of Chargebacks x Chargeback Fee)
>
>   Total Charges =  10 + 100 x (10 x .025 + 0.3) + (5 x 15) = $140
>
> MERCHANT COST = 14%
>
> So it is clear that this solution is too much tricky and expensive,
> even if we would have some thousands transaction per Month the cost
> will be always around 14% (never less then 13% till some millions
> transactions). Even more is really hard to develop, the security risks
> are too many and too dangerous to even consider this option.


> Payment Gateway
> ===============
>
> I just provide an example, http://www.authorize.net/ , this is the
> most used and he accept several different kinds of payment systems.
>
> The advantage is that we have almost nothing to develop, we just
> need to use some APIs to connect to the payment gateway, that will
> take care about all the rest of the transaction.
>
> The cost? It's not clear, what we need is not a standard product...


> eMoney
> ======
>
> This is the most attractive solution, we don't need to develop
> anything then a logging interface for legal purpose.
>
> It should be clear I'm speaking about PayPal, but there is another
> provider that has a great advantage compared to PayPal, it doesn't
> have fees, Neteller PLC is a publicly traded company on the London
> Stock Exchange Alternative Investment Market.
>
> Customers can transfer money from their Neteller account to merchants.
> The service is often used to transfer funds to and from online
> gambling sites, so customers can also receive funds, such as winnings,
> back from merchants to their Neteller accounts.
>
> The cost of transferring funds from Neteller accounts to and from
> merchants is free to consumers because, as with credit cards,
> merchants cover the costs.
>
> http://www.neteller-group.com/
>
> PayPal fees: http://www.paypal.com/cgi-bin/webscr?cmd=_display-fees-outside

IMHO the "GNU Herds virtual bank" feature could be a better option than 
Neteller accounts due to "GNU Herds virtual bank" will not has any fee.
Read [2].

  [2] http://lists.gnu.org/archive/html/gnuherds-app-dev/2008-03/msg00019.html


GNU Herds could add the support to other methods as a way to make it easier to 
get into the "GNU Herds virtual bank" functionality.

IMHO, ideally, what the GNU Herds project needs is something as what is 
exposed at the above PayPal link but without any charge of any kind for any 
of the sides: 'customers' or 'merchants'. That is needed to allow anybody can 
micro-donate $0.02.



> ---
> References:
>
> http://en.wikipedia.org/wiki/E-commerce_payment_systems

As there are a lot of payment systems [1], GNU Herds could add one more to the 
pile, with the service free of any charge for GNU Herds users.
  [1] http://www.onlinepaysystems.info/


> 
http://economia.repubblica.it/articolo_cribis/I_sistemi_di_pagamento_online:_caratteristiche_e_sviluppo_del_settore/156021
 
(it)

That Italian article is a very good.


> http://en.wikipedia.org/wiki/PayPal
> http://en.wikipedia.org/wiki/Neteller

> http://www.findmyhosting.com/web-resources/Articles/internet-merchant.htm
> http://en.wikipedia.org/wiki/Guide_to_E-payments


--
As usual, please expose any disagreement, correction, etc.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]