search

CORE-POS / IS4C

Cooperative Operational Retail Environment
http://www.core-pos.com
GNU General Public License v2.0
63 stars 44 forks source link

Help understanding Lane input for CC processing... #1222

Closed jamesTSCoop closed 3 months ago

jamesTSCoop commented 4 months ago

Question!

I'm implementing DcDirect support as a Paycard module, but being a systems programmer I've done my work from the bottom up. Now at the point of testing stuff I realise I don't understand the lane input and input parsing that brings control into my new Paycard module. The DcDirect module is part of RegisteredPaycardClasses, but I can't figure out what paycardEntered::check()/parse() are expecting, except that ending an input with '?' seems to get me there. Also how 'PV', 'AV', 'AC' are meant to be used etc. Maybe this is written down somewhere and I missed it? I shoulda sorted this out earlier, DcDirect is so contained compared to the other Paycard modules it might even be better implemented as a separate plugin from Paycard entirely.

gohanman commented 4 months ago

Any class that extends COREPOS\pos\parser\Parser may get a look at input (there aren't guarantees about order and the first module that returns true from check() is assumed to handle that input. I'm speculating a bit without knowing anything about DcDirect but https://github.com/CORE-POS/IS4C/blob/master/pos/is4c-nf/plugins/Paycards/lib/PaycardDatacapParser.php might be a better module where it's just looking for keywords to redirect the browser to a page within the plugin.

To explain the history of this a bit, paycardEntered was version 1 and was originally watching for plaintext magnetic stripe data (that's what the ? is catching), and then later encrypted magstripe data formats. At least in the US, the rollout of EMV was the end of the POS being allowed to handle card data in any format (at least for small developers). That's when PaycardDatacapParser comes in.

The original architecture was that the PHP side would submit an HTTPS request to the processor, including the card data, and then get a response back. When we moved to Datacap - which may or may not be similar to DcDirect - that had to make some extra hops. The PHP side would still assemble most of the request, but then it'd make an AJAX call to submit that request to pos.exe over HTTP. From C# it can call Datacap's library functions which handle collecting the card data and communicating with the processor. It then relays the processor response back as the reply to the AJAX call, and that gets POSTed through a hidden form so finally PHP can once again deal with parsing and storing the response.

PV, AV, and AC are all gift card related - balance check, add value, and activate, respectively. I'm not sure why PV came to stand for balance check; that pre-dates my time working on the code base.

roberski commented 3 months ago

'PV' also the products search command in the Steering.php parser and I've never understood why, maybe the naming is related?

joelbrock commented 3 months ago

FWIW:
PV - was short for "price/product verify" BQ - was the IS4C balance inquiry code and it stood for "balance query"

Any other ancient arcana I can unearth?

flathat commented 3 months ago

BQ is for Store Charge, a run-a-tab or pay-forward the member has with the store, is also CORE-POS. But not related to payment cards.

jamesTSCoop commented 3 months ago

Thanks so much everyone for the knowledge, very much appreciated. Everything is coming together now, full steam ahead!