Custom Module, Credit Card processing using Samba

[aloupos]

Emre -- the improvements to external processor are perfect.  I'm following the patterns you've set there, which were a bit of a learning curve but helped me a lot to not soil your seriously clean code. 

John, I'm integrating to the authorize.net api, which seems to be the standard API for web commerce.  My merchant vendor, paynet -- which is not directly affiliated with authrorize.net has mirrored that api as well.  Most shopping carts use this api.  The only difference among these merchants is obviously the url, which I'll put in the settings. 

I'll implement this using an abstract class so we can plug in additional processors for chip and pin. 

Edgar, our notation for displaying credit card numbers is identical, so I'll follow suite. 

So far I've just about finished the UI elements, including forms for pre-authorize, authorize, manual credit card entry and tips. 

I still need to complete the api integration and print integration. 

Emre, obviously we use the standard printer templates, but we need to add some additional fields, for the name, credit card number, etc.  How should I proceed?

[aloupos]

Another question is the TIP.  Maybe I missed it, but can I add the TIP to the bill in code?

[emre]

Anthony I hope you are having fun while implementing that.
Basically we'll create two service templates. One for Gratuity and the other one for Tip. User will enter Tip amount. We'll read Tip Service Template name from processor settings and add tip amount as a service like we did for gratuity. We'll use service templates because on Work Period Reports we need to see these amounts separately. We can also print them in detail.

I'll improve printing for sending custom tag values. I'll wait your fist commit for implementing it.
Thanks.

[emre]

I'm asking it to be able to ensure I'm not misunderstanding something. Are gratuity and the tip same thing or they are separate amounts?

[aloupos]

Nope.  They're the same.  Let's just call it Gratuity from now on. 

[emre]

There is an implementation for fixed amount Gratuity at external processor implementation. Basically we need to create a service template named "Gratuity" and configure the external processor for using this template while calculating gratuity. If fixed rate gratuity is configured as 0 than we can ask user for the gratuity amount at force stage.

[aloupos]

I think that will work fine.  I just did the first commit, which includes the GUI, Paynet interface and some workflow changes.  Can you take a look and see if you agree with my implementation so far?

Also, there's one scenario we didn't think of that's pretty important.  That's splitting the bill across credit cards.  In this case, we would need to pre-auth more than 1 card, issue receipts for customers to sign and write gratuity, then go back to the ticket and force all transactions.  I think we need to store the card data and the amount in an array or dictionary attached to the ticket until the ticket is closed. 

[emre]

Anthony, Where did you uploaded your commit? People created lots of test clones so I couldn't find yours..

[aloupos]

Actually, I tried to commit the changes back to your trunk, but I'm getting a 404 error from hg.  I've never used googlecode before.  Any ideas: 

C:\Documents and Settings\anthony\sambapos2\sambapos>hg push
pushing to https://code.google.com/p/sambapos
searching for changes
http authorization required
realm: Google Code hg Repository
user: aloupos
password:
abort: HTTP Error 404: Not Found

[aloupos]

Never mind, I created a clone and pushed to it. 

https://aloupos@code.google.com/r/aloupos-credit-card/

everything should be there.

[emre]

Anthony, Yes, you'll work on a clone and I'll merge your changes to main repository so you won't overwrite my changes

I reviewed your code and it seems great. On first version we can skip multiple credit card processing and manual cc number entry. After you complete force implementation I'll merge it with main repo and implement custom printing for gratuity. After completing the first workflow cycle we can think about the multiple cc processing and manual cc number entry. I have an idea about multiple processing but first I need to improve ticket printer for printing barcode.. If it sounds fine to you I'll be waiting for your merge request.. You can continue submitting on your clone. After I merge it with main repo with my changes you'll create a new clone again and continue implementing from latest state.

[aloupos]

Fantastic, I'll wrap up the force, upload and send a request to merge. 

[jeni]

Your software has really some good and advanced features, it’s really awesome. But have you include some encryption technique in it while inserting the credit card no.

[kenerly]

So can you process credit card payments with samba now?

[aloupos]

Most of the work is done, but new rules for PCI compliance that will begin to be enforced in the US (and probably already are in Europe) will mean we need to re-think some of the workflows.