eCheck or ACH
I'm testing out your billing software and I'm very impressed. Great job! I would start using it now for my business but I don't see the option to process payments using eCheck or ACH. Why do you not offer this payment option? It will save me a lot of processing fees to use it.
Thanks,
Jack
Discussions are closed to public comments.
If you need help with Cheddar please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Marc Guyer on 16 Nov, 2010 03:52 PM
The main reason is because ACH doesn't guarantee funds. There's no guarantee that the customer has entered their account information correctly. Account holders can reject a transaction for any reason. It also adds a significant increase in the potential for fraud.
2 Posted by Jack on 16 Nov, 2010 04:18 PM
Isn't CheddarGetter just providing the software for me to communicate with the payment gateway? If fraud were to occur or account information was entered incorrectly and a payment failed, you guys would assume no liability. The gateway would communicate directly to me. Unless my assumptions are wrong, why not officer ACH if you are not help liable?
Support Staff 3 Posted by Marc Guyer on 16 Nov, 2010 08:02 PM
It's not about legal liability to CheddarGetter. Adding ACH as a payment option complicates the process, particularly with dunning management and auto-cancellation. This, in a sense is a liability to CheddarGetter in increased complexity of the system and and increased support burden.
For example, with credit cards, CG immediately knows when a customer's payment has been declined. CG communicates with the customer automatically to drive the process to correct the error. The error can be corrected quickly and again, CG knows immediately that it is either corrected or not. If the error is not corrected during this process, the customer's subscription is automatically canceled.
This process would be quite different in the case of ACH. It can take several days to learn if an ACH transaction was successful. In order to know whether or not a transaction was successful, CG would have to periodically ask the processor if recent transactions were successful. Typically a "successful" result is learned within a couple of days but a declined payment can take longer to "settle" in declined status. Then the dunning management would start. The customer then submits another payment attempt to correct the error. Again, several days pass before CG knows if it resulted in success.
Long story short, CG was designed to reduce the labor involved in managing a billing process for large numbers of customers. The sweet spot is high volume, relatively low dollar transactions. ACH only starts to become compelling when the environment is right. For example, low number of customers with high dollar transactions. Or, if your business inherently has a high level of trust with its customers.
4 Posted by Jack on 17 Nov, 2010 10:34 PM
Thanks for your response. This all makes sense and I can see how ACH transactions do complicate things.
Support Staff 5 Posted by Marc Guyer on 18 Nov, 2010 03:58 PM
You're welcome. We even took this opportunity to blog about it:
http://blog.cheddargetter.com/post/1610162759/why-we-dont-support-a...
Marc Guyer closed this discussion on 18 Nov, 2010 03:58 PM.