English Boards > Support
Custom Module, Credit Card processing using Samba
emre:
Anthony...
You can fetch latest state from googlecode repo and my sample implementation is ready to compile. You'll find CreditCardModule library in project. It will support multiple processors so when needed we'll be able to implement additional processors easily. John have something similar about integrating POS devices.
When this library loads we'll see an additional field on Local Settings screen for choosing and configuring default credit card processor.
I've implemented two sample dummy processors. Simple processor will demonstrate processor configuration, saving configuration values and basic interaction with operator. External processor demonstrates implementing custom UI. You can try adding a third processor by duplicating one of them.
I'll be waiting your questions..
aloupos:
Emre, Thanks for the speedy update. I downloaded the source and started playing around with it last night. As you expected, I have a few questions. I'll fill you in on some background for cc processing in restaurants in the US first.
Compared to Europe and Asia, we're still old school when it comes to processing credit cards. Here's how it works in most restaurants in the US.
[AUTH]First we run what's called a pre-auth, which basically asks the credit card company if the card holder has enough credit for the amount + a 20% gratuity. We do this because the customer will manually write in the tip amount later.
[SIGN]Second, a receipt is printed that contains the tendered amount with a blank space for a tip and of course a signature.
[FORCE]This receipt is then returned to the cashier, who enters the tip information and runs the actual charge, called a Force.
[CLOSE]This ticket is completed, the cashier can re-purpose the table if in ala-carte mode.
Q1. Given the above, I need temporarily persist some credit card information, along with the state of the transaction. I think it makes sense to attach this information to the ticket model. How would you recommend I do that?
Q2. The TIP that the customer gives should also be attached to the ticket. I can just create a non-taxable item called Tip and add it to the ticket, but it seems like a bit of a hack. Is there a good way to add the tip to the ticket?
Q3. We'll likely need an additional management screen to perform voids of transactions. This probably shouldn't be done through a ticket, as the ticket may have been closed by the time a mistake is discovered. Also, it's a theft risk if cashiers can just void charges. Where/How do you recommend I add that?
emre:
A I've said earlier my experience about it is limited so I'll ask a question. Even keeping cc numbers in memory is risky. Shouldn't merchant store pre-authorized credit card numbers remotely? I think the process should be :
Pre authorization -> merchant returns a unique authorization number -> we complete process with that authorization number (not with the credit card number)...
Even I'm wrong with my assumption I think there is no need to persist credit card numbers anywhere. We can store card details in memory as a dictionary with a unique key until we need them for completing process. How it sounds?
aloupos:
That would certainly make a lot of sense, but the merchants I'm familiar with don't work that way. Based on the following, it looks like we need to temporarily persist the credit card details:
"FORCE – Indicates a closure of a previously PREAUTH (pre-authorized) transaction. A
FORCE requires all data fields submitted with the original pre-authorization plus the
additional variable named APPROVNUMBER. The value of this field is the original
transaction Approval Number returned as the value of Approv_Num." -- from the merchant API guide.
I agree that we don't need to persist anything in the database. Is the best way to create a global dictionary with the ticket number and cc details?
emre:
Yes keeping it in a dictionary will be fine. So we'll need a CardDetails class for keeping required values in memory and add it in a dictionary keyed with ticket number. We can use SecureString class for storing Card numbers in memory for additional security.
CreditCardProcessingData contains Ticket property for passing actual ticket data. If we talk for External credit card implementation you can store it in a private variable and instead of calling "PaymentProcessed" event you can call _ticket.PublishEvent(EventTopicNames.PaymentSubmitted); for closing ticket without completing the payment. So on first click to credit card button you'll pre-auth it, print receipt and close ticket. On second click to credit card button you'll check dictionary and if you can find preauth data with ticket number you'll force payment and remove preauth data.
Of course that will mean we should complete cc processing from the terminal we started the process. If we enable CC processing for a single computer it will be fine. For voiding payments we should store processed payment data elsewhere... SambaPOS permits payments with multiple credit cards so... hmm... If you think it will work as I described I can improve my implementation, tomorrow.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version