Spectrum Session Q&A-Shift4 with Prism Products

Is there a way to allow the customer to insert their card before approving the amount being charged?

This question is related to retail POS at the register where pin pads are involved.  We currently do not have this feature available at this time.

Why are we having issues with this, MC and Discover work but Visa errors out?

This is an issue we are working on with Shift4 where for some reason for this specific card type and processor, there is an issue/missing piece.  We are hoping to have that fixed very soon and will let you know once they have made the change/adjustments.

If the transaction has 2 tenders, credit card and on-campus charge, why does POS not pre-authorize the amount instead of authorizing? If the 1st tender is approved & the 2nd is declined & the customer doesn't have another payment method, we get ourselves in a pickle!

The way to avoid this it to enter the cc first.  If that did not happen the work around would be to complete the sale with some other tender, i.e. cash, and then issue a refund.

How specific is the AVS in the name and address field?

You can customize those settings to what works best for you needs.  It can be high sensitivity, medium, low or customizable. Be aware that your shoppers were previously used to being able to enter anything in the card/address fields and allowed to place their orders.  There will be more calls/declines in the cart because people have incorrectly entered their information and it will prevent them from purchasing until the settings you have chosen to check against are entered correctly by the shopper.

Address verification is very tricky.  There is no set standard across the industry as to how the address is actually formatted/checked.  The best thing to do- take a look at statement from CC issues.  That address that is exactly on there is what is being looked at.  One back issuers formats can vary—databases are structured differently.

In PrismWeb Manager, under reports, you can look under your reports tab for the credit card auth errors to help troubleshoot issues. 

We have had customers who enter their street and zip correctly, but our website will not let them proceed.  We do required street address and zip to match. Reason?

This may require some trial and error with what settings you have checked and what you want to check against.  It is a little more in depth than what the 3 sensitivity levels describe.  You can see what rules are allowed:

                                                               i.      High - Fail any confirmation of name, street, or zip mismatch.

Allows values BDEGIJMPQRSUVXY

                                                             ii.      Medium - Fail any confirmation of street or zip mismatch. Forgive name mismatch.

Allows values BDEFGHIJMPQRSTUVXY

                                                           iii.      Low - Fail any confirmation of zip mismatch. Forgive name or street mismatch.

See the chart below with the Letters and corresponding values meaning:

Open

We moved to Shift4 early on with the promise of P2PE in our Canadian store.  Years later this remains an unfulfilled promise.  Now we are being told Shift4 and Moneris aren't working collaboratively to support PCI certified pin pads.  Moneris is saying that they are willing to work with Shift4 so I'm left to question where the roadblock really exists.  Is there an update on Shift4/Moneris/P2PE efforts for Cdn PrismRBS customers?

From Shift4: Over the years, we have been wanting P2Pe in Canada> the devices that used to be in place used RBX ingenico firmware which did not support our p2pe.  Until a year or so ago we did not have the ability to do P2Pe in Canada. Period.  Now with the Tetra product line, Ingencio released a more common standardized version of their firmware and so what is in the US in the same as Canada.  We do currently support the Tetra products in the US on two platforms right now.  We have not gotten the certification yet for Canada with these devices. We have to certify the integration with the Tetra devices with the Canadian processors, Moneris, Chase, and Global Payments.  And all the US based processor as well. That is something we are working on—getting the updated device list. Currently looking at another manufacturer as well, Pax, to see if we can make that a faster path. It is something I expect to be done during this year, especially with Moneris—who is our largest processor and the first we will do anything with

I have created a ticket with Prism and they had me create a ticket with shift 4 on the Verify issue where Visa errors and MC and Discover work

That is exactly what you should do.  We will update all customers who are having this issue once it has been resolved.

Follow up on my Shift4/Moneris/Cdn question.  We're being told our current IPP's are out of compliance at the end of April.  What is the replacement solution you are offering?

From Shift4:  One of the things that is misunderstood.  The devices going out of life, those devices are no longer approved for new installations. If you are an active merchant who has been using these devices for years nobody is saying these devices are no longer allowed to be used.  They are still fine devices.  They have P2Pe in the US, tokenization, they have everything they are supposed to have and meet all the requirements.  No one is saying you need to flush them away and get new devices.  As long as they are fine, there is no issue with them just because the date has passed, or they are expired. They are still valid devices.  You could not go open a new location with those devices, then you could get into some technicalities, but as far as an existing merchant using existing devices—it is not a problem.

Moneris is saying that they might not have replacement devices if their current inventory is depleted

From Shift4: That is a valid point. WE understand and are trying to come up with a solution for you.

So what is our solution?

My understanding was that we need to replace them before our next PCI Attestation. Is that not correct?

The devices are expiring so they are unable to be brought into new locations and used, but as far as needing/wanting to replace them, that needs to be determined by your QSA and not necessarily needing to be replaced before your next PCI attestation.

Here is another resource on this: https://www.pcicomplianceguide.org/pts-poi-v3-device-expiration/