Hello All,
I'm a developer working on a web-based restaurant POS system. This is my first project handling payments that aren't made online, so I have a ton of questions.
My plan is to basically allow waiters to swipe a card (and get submitted to my server via an ssl secured form), the information will be passed to the authorize.net servers through an API for authorization. My system will then print a receipt with an authorization number on it for a customer to sign. Once a customer signs the receipt and declaires a tip, the waiter will go back to the terminal and enter the tip. My server would then communicate with authorize.net again through API processing the payment.
Mainly, My questions are -
Is authorize.net capable of processing credit card payments at a location?
Will I need guests to sign receipts still?
Which type of API would you recommend to accomplish this?
Would each restaurant have to get their own Authorize.Net account?
Is this even possible?
I might even end up doing two seperate transactions, one for the bill and one for the tip. I heard that most restaurants do all their processing over night in one batch, which I might do as well? - What would you recommend on that?
Thank you for any insight that anyone can provide me, I really appreciate it.
Thanks,
Jon
12-15-2011 11:36 AM
> Is authorize.net capable of processing credit card payments at a location?
Yes. A card present account is required.
> Will I need guests to sign receipts still?
Yes. This is a requirement of the merchant account. Not Authorize.Net.
> Which type of API would you recommend to accomplish this?
I believe AIM would suffice.
> Would each restaurant have to get their own Authorize.Net account? Is this even possible?
Yes. In fact they would each need their own merchant account.
> I might even end up doing two seperate transactions, one for the bill and one for the tip. I heard that most restaurants do all their processing over night in one batch, which I might do as well? - What would you recommend on that?
You can do tip adjustments for restaurants. The merchant account provider can tell you more about that.
12-15-2011 11:41 AM - edited 12-15-2011 11:42 AM
The customer is probably not going to want to give up their card a second time so the tip can be entered (I wouldn't). If you're doing things this way, you're better off using CIM to set up a payment profile the first time, then processing a second charge against the profile when a tip is declared. Any other way of doing things requires either waiting until the tip is declared (which means problems if the credit card info is bad and the person left after receiving their reciept), or taking the credit card twice (which as I said, customers will find very annoying).
12-15-2011 02:39 PM
Thank you stymiee, I really appeciate the quick and informational reply! You have no idea how much that helped me.
I have done some research on this and have found the differences between a merchant account and a payment gateway.
So please let me know if I have this correct.
I would need to construct an application that worked with Authorize.net's API. I would need customers to get both a merchant account and an authorize.net account for payments to work properly.
The thing that i'm not clear on is if I can get a merchant account from Authorize.net?
Thank you so much!
Thanks,
Jon
EDIT:
@ TJPride
Thanks for your reply! I really appreciate it!
I would agree that would be annoying taking the card twice. I guess i'm planning to have the waiter swipe the card once, and run an authorization in addition to storing the track data temporairly (PCI compliant of course). Then when a waiter closes the ticket with or without a tip, the final amount would be charged to the card.
Great points and thanks for the reply!
Thanks,
Jon
12-15-2011 02:59 PM - edited 12-15-2011 03:04 PM
You can get a merchant account through Authorize.Net. You can get it from any of their resellers as well.
If your merchant account is set up properly there is no need to run the card twice. You will be able to add a tip amount to the original transaction simply by referencing the originial transaction.
12-15-2011 03:37 PM
Is that something that's different for card-present accounts? Because I'm pretty sure you can't adjust web site transactions. Maybe today is my day to learn something.
12-16-2011 07:08 AM
Yes. You can only adjust card present accounts and only ones that fit into certain SIC codes. And even then that differs between Visa and MasterCard.
12-16-2011 07:33 AM
@stymiee : I haven't been able to find a transaction type that I can submit to Authorize.net that will do what you are suggesting. I know this is possible through many other payment gateways. Ideally I would like to avoid the Auth/Capture pair of transactions, like is possible with our other integrations. Perhaps I am missing something in the documentation?
Thanks in advance!
-Trevor B
07-03-2012 10:59 AM
I too need to be able to send "re-auth" for a higher amount, or capture for funds higher than the originally auth'd amount on a card present account. How can I do this? It's not only need for tips, but for the bar industry (where tabs are constantly being changed/updated).
09-15-2012 01:31 PM - edited 09-15-2012 01:33 PM
Unfortunately, Authorize.Net does not currently support any functionality that allows for capturing for more than the original authorization. It is true that card issuer policies do allow this for service industries, but it isn't available when using our system.
In reference to a bar tab type of scenario, this isn't allowed regardless of the system used. I am not aware of how most bars handle these type of payments, but it is never possible to repeatedly adjust an outstanding authorization.
09-21-2012 01:24 PM