Closed jamesTSCoop closed 3 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.
'PV' also the products search command in the Steering.php parser and I've never understood why, maybe the naming is related?
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?
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.
Thanks so much everyone for the knowledge, very much appreciated. Everything is coming together now, full steam ahead!
Version of CORE? head.
Issue with Office, Lane, or both? Lane
Is this [mostly] a bug report, feature request, or question?
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.