In the early days, when computer networks and processing power of point-of-sale and payment terminals was limited by then current-technology, the focus was on efficiency. Payment transactions generally only contained a few data elements of data required to process the transaction, and implemented technically in a manner that saved as many bytes as possible. This was important so all of this would work over a dial-up line and only send required data for transaction processing. Much of the payment message formats are tied to this legacy heritage to this date.
In the world of 'Big Data' there is a growing trend of providing fatter transactions, and providing more data in these transactions. These transactions consist of more then the final amount of the transaction and payment information, but now with market basket data and line item detail.
What does this involve from a payments system perspective ?
1) Expanding message formats and APIs to include list of skus and UPCs and other meta-data of market basket items.
2) Processing against a catalog to perform various value added services and processing.
3) Parallelism in transaction processing as certain items require processing that would take too long if processed in a serial manner.
4) Development of systems including robust engines and processing logic leveraging Machine Learning techniques to mine and process such data.
This isn't new in concept as it has been performed locally in retailers for sometime now, as well as in some level-3 purchase/commercial cards. Now there is a trend of more value added services to enhance payment processing such as item based loyalty rewards, when such data is available you have more options and capabilities to enhance the payment transaction.
We were discussing Result Codes (aka. Response Codes) during a call today. We were discussing both "Soft" and "Hard" Declines and the differences of them in the context of reviewing a payment interface and which transactions could be Store-and-Forwarded ('SAF').
Result codes are returned in Field or Data Element 39 in an ISO-8583 message.
We use the term "Soft" decline when a subsequent transaction request containing the same pertient information could recieve a different result.
These typically occur from a transient system issue or payment network issue and are temporary in nature.
Hard declines contrast from Soft declines in that on a subsequent transation request, the responses are repeatable; you will recieve the same result.
Situation: What happens if you send a financial transaction to a payment system and we don't get a response back? You are obligated to reverse it and keep on trying to reverse it (reversals are normally Store-and-Forwared (SAF) until you get a response back that the reversal was accepted.
You would be surprised how many implementations of payment software do not implement this important step, a disaster of not performing this is duplicate charges to cardholders during system or communication issues. This needs be be implemented in each path of a transaction. Terminal to Gateway, Gateway to Switch, Switch to EndPoint. for example. Many applications get-by, by ignoring reversals on Credit product types where cardholder have large open-to-buys and on Authorization Only Transaction Types. Reversal for Debit and and other financial transaction sets are a must.
Idempotence ( /ˌaɪdɨmˈpoʊtəns/ eye-dəm-poh-təns) is the property of certain operations in mathematics and computer science, that they can be applied multiple times without changing the result beyond the initial application. The concept of idempotence arises in a number of places in abstract algebra (in particular, in the theory of projectors and closure operators) and functional programming (in which it is connected to the property of referential transparency).
Problem: Network and server hardware failure can lead to lost messages, resulting in cases where a service consumer receives no response to its request. Attempts to reissue the request message can lead to unpredictable behavior within the service and the service consumer logic.
Solution : Design service capabilities capable of safely supporting repeated message exchanges.
Our implementation of reversals can handle multiple attempts of a reversal, we only process one but will accept any number of them. This is very important, Reversals are not "approved" or "declined" as the endpoint may or may not need to unwind anything. You as a caller don't know whether the timeout was actually not processed at all, or if it was processed but you just didn't get the response back.
We have the following ISO8583 v2003 based result codes in OLS.Switch for this so we can note the difference.
It really depends – There are two models in play here, a) you can pay a terminal manufacture to development a terminal application, b) terminal manufactures also generally will sell SDKs, Software Development Kits, as well as required or optional training courses for independent developers to write payment applications for. From my personal experience, we have worked with both terminal manufactures as well as independent developers, as well as wrote very few in house.
Payment Processors and/or payment gateways will provide either dial 800 numbers for dial payment terminals or an IP address or https/SSL based URL for IP/SSL based terminals to send transaction data. OLS has integrates to various dial concentrator devices/networks – Hypercom NAC, TNS, HB.Net, now Phoenix Managed Networks, for Dial delivery. We have developed our own secure SSL Transaction Servers with various interface options for our customers, IP SSL Sockets, HTTPS Post, RESTful as well as SOAP based web services.
Great question, A cash withdrawal is generally associated to a ATM or Debit Transaction where the full transaction amount can be immediately debited by the Card Issuer and Cash Provided to the Card Holder. While a Cash Disbursement transaction is generally something a Card Holder can request at a financial institution that he may not have a relationship with – Think of a cash advance of your Visa or MC card at a Bank, or if you have prepaid card or payroll card that you need to get money or cash from at a credit union that you don't have an account with.
I have a lot of problems with this.
2) I find it hard to dispute that: Direct Connection > VPN > SSL over internet from a general security perspective.
5) The concept of "least privilege" from a networking perspective is not followed – only two parties need to talk to each other, why open it up to the world to attempt to connect to ? Another interface stated "We restrict all traffic by third party connections to the least access needed to support business. " <– I like this much better.
6) SSL over the internet will require our customer to expose a secure internal system to the internet, when it was designed to have very controlled network access, as compared to a VPN and general firewall rules for network control.
7) I haven't discussed direct connections or leased lines, mostly due to the nature and volume of this application. Normally this is our first choice for high volume, sensitive transaction data to third parties with multiple data centers. Where we use 2 leased lines on different carriers to different data-centers.
My Vote for this? SSL over a VPN – (Defense in depth) Could SSL be used ? Sure but we would need to add a list of controls around its implementation and quite possibly add a layer of applications (proxy the requests) to design around this which is more work and has a higher change of configuration failure then a standard site-to-site VPN connection.
Over at this link at FDR there is an excellent summary of the new ATM requirements for the Americans with Disabilities Act that goes into effect on March 2012.
1. The merchant must have validated PCI DSS compliance previously or have submitted to Visa (via their acquirer) adefined remediation plan for achieving compliance based on a gap analysis.
2. The merchant must have confirmed that sensitive authentication data (i.e., the full contents of magnetic stripe CVV2 or PIN data) is not stored, as defined in the PCI DSS.
3. At least 75 percent of the merchant's transaction count must originate from enabled chip-reading device terminals (i.e., contact and/or dual interface contact/contactless terminals).
What about US Merchants ?
I think this announcement adds a new dynamic in the form of a potential incentive as it relates to EMV adoption in the US. US Merchants may now, in the near future, have an incentive or a discount to consider for EMV implementation (assuming implementation of EMV processing infrastructure) in the form of less annual PCI compliance validation costs in the form of on-site audits to offset implementation of new card acceptor devices and updated payment software to support EMV.
If I use EMV we don't need to be PCI compliant !!!
Although Visa may waive the annual validation requirement for qualifying merchants, all merchants are still required to maintain on-going PCI DSS compliance. Acquirers retain full responsibility for merchants' PCI DSS compliance, as well as responsibility for any fees, fines or penalties, which may be applicable in the event of a data breach.
Whats the difference between Current and Available Balance ?
Current balance is the real, financial balance.
Available balance is the current balance minus any holds.
An auth does a hold – it affects only available.