Global Payments (Realex Payments) Important changes

[guccij]

Another email from Global this afternoon, including this part:

Ecommerce Transactions
❗️ Payments made via a website require SCA. These transactions must now support 3D Secure, which is the ecommerce authentication protocol by the Card Schemes, such as Mastercard and Visa. This allows the cardholder to authenticate themselves at the genuine holder of the card. Under PSD2, card issuers are obliged to challenge and potentially decline transactions that don’t comply.

A new version of 3D Secure (3D Secure 2 – 3DS2) is being introduced to comply with new regulations and provide a better customer experience, more security for your business and a frictionless payment experience. Read our blog called 3D Secure 2 – A Beginner’s Guide on our website.
What do I need to do?
If you use our Global Payments E-Commerce Platform (previously Realex Payments), this will support 3DS2 from September 2019. You should have already received communications from us about the changes you need to make to comply with the new SCA requirements. If you’ve any questions about the changes or would like more information on our E-Commerce Platform, please email ecomsupport@globalpay.com.

If you use a third party provider for your ecommerce services, you need to review the way in which you accept card payments. Please speak to your solution provider to make sure your solution is up to date with all the flagging requirements and that they’re making changes for the SCA mandate. Our 3DS2 solution may be used alongside your existing gateway solution, if required. You can contact us on the email above for help with this.

Details of the technical requirements for SCA can be found on our website within our Customer Centre under the Strong Customer Authentication tile.

[Mike Hughes]

Thank you for your continued update and input. We are aware of all the points raised and are working on an overall solution to the updates in PSD2, including SCA and 3DS v2. This includes analysis of Sellerdeck users and their software versions and the impact across as many scenarios as possible so that a clear and simple message can be delivered.

Further information will follow, thank you.

Josh, assuming someone has been tasked with this, is there any kind of timescale for letting us know the outcome?

My own impression is that for ecommerce this is largely a requirement that's being handled by the card issuers and PSP who have to be able to handle the new verification process and protocols. I think as users of Sellerdeck there should be minimal impact but we do need a clear message from Sellerdeck to confirm this.

[feemish]

I imagine it's just about passing some extra details.. like the phone number?

[Mike Hughes]

i originally thought that too from the documentation I'd seen, but I suspect the card issuers want to send the text to the phone that is registered with your bank rather than whatever phone number gets entered by the purchaser as otherwise it wouldn't offer much in the way of verification of identity.

But this where it all gets complicated. If the bank has my mobile phone number, is it allowed to pass that information to the card issuer or is it just allowed to confirm the one you've given it during checkout? I'd imagine it's less of an issue if your card has been issued by your bank but lot's of people have third party credit cards and the system needs to work for them as well.

The complexity to me is really the processes and protocols between the PSPs, Card Issuers and Banks. The requirements on Sellerdeck should be fairly minimal if any. But as before a full answer and statement is needed.

At a guess I'd say there must be something that's needed by Sellerdeck otherwise we'd probably have had an answer by now. The time it's taking suggests that some changes are needed so they need to spend a little time working out exactly what it is, what the implications are and what is needed to implement them.

[feemish]

ah yes.. true.. well lets hope that Sellerdeck look into what's required soon then!

[Josh Barling]

Hi All,

Thank you for your further comments.

Sellerdeck Desktop currently has 20 PSP integrations and we are gathering information ready for an announcement that informs all our customers. As you can imagine, this is a challenging task and also complicated by the fact a lot of PSPs are still working on their position.

It is true that the requirement and responsibility is not solely on Sellerdeck and in some cases there are no changes or development required.

I appreciate you are looking forward answers as soon as possible; I can reassure you that we understand the important of 3DS v2 and that it is a requirement that cannot be ignored and the deadline cannot be missed.

Once we have all the relevant information we will share this with all customer.

[feemish]

Only 5 weeks till this change starts to go live

"On the 19th August, we'll start to return this new element in our production environment."

New Data Element

To support the Strong Customer Authentication (SCA) requirement that's due to go live in September 2019, we'll be making a change to the messaging we return in some of our card transaction responses. Mastercard and Visa assign an ID to every transaction, which will be a key piece of information post the September SCA change. Mastercard refer to this ID as a Trace ID, while Visa refer to it as a Transaction ID. Collectively, it's referred to as Scheme Reference Data (SRD). We'll be returning this ID in our transaction responses, in a field called SRD. This is a valuable piece of information that aids, among other things, accurate matching of authorisations to completed transactions. For SCA, this is vital for ensuring the success of Merchant Initiated Transactions*. What will change? If you're using our API or Hosted Payment Page (HPP), a new data element called SRD will be returned for the following request types: auth auth-mobile otb receipt-in receipt-in-otb query settle void offline rebate refund Please note, this element can be blank. What are the benefits? Identification: The SRD can be used across the payment lifecycle to identify a transaction to all parties: the card issuer, the acquirer, the payment gateway, and the merchant. If you have any communication about a transaction, the SRD can be used to locate the right one. This is particularly useful when dealing with chargebacks or customer queries. Merchant Initiated Transactions: Card issuers will see a clear payment history between the cardholder and merchant, which allows them to link the cardholder's authentication and initial payment with subsequent Merchant Initiated Transactions. How does this affect me? Transaction processing issues aren't expected as a result of this change, however, if your system expects a fixed format response message, it may need to be updated to accept this additional piece of information. What do I need to do? All merchants: From the 22nd July, we'll return this new element in our sandbox environment and we recommend you or your developer attempt a sandbox transaction. If you process a test payment and your system operates without issue, the change won't affect your system. If your system does encounter an issue, please contact our support team on the below details, and they'll work with you to resolve it. On the 19th August, we'll start to return this new element in our production environment. If you have any problems receiving responses from us to your system after this date, please contact our support team and they'll work with you to resolve it. If you process Merchant Initiated Transactions: You'll need to store the new SRD value that's returned on the first transaction, so that it can be referenced in subsequent transactions for that cardholder. This will ensure that the card issuer can identify the cardholder's payments as linked. What are the technical details? API Response Below is a sample response with the new field highlighted with sample SRD value 'Sample123456789': <response timestamp="20180731090859"> <merchantid>MerchantId</merchantid> <account>internet</account> <orderid>N6qsk4kYRZihmPrTXWYS6g</orderid> <authcode>12345</authcode> <result>00</result> <cvnresult>M</cvnresult> <avspostcoderesponse>M</avspostcoderesponse> <avsaddressresponse>M</avsaddressresponse> <batchid>319623</batchid> <message>[ test system ] AUTHORISED</message> <pasref>14610544313177922</pasref> <timetaken>1</timetaken> <authtimetaken>0</authtimetaken> <srd>Sample123456789</srd> <cardissuer> <bank>AIB BANK</bank> <country>IRELAND</country> <countrycode>IE</countrycode> <region>EUR</region> </cardissuer> <sha1hash>8f4dfe7460ce91f78a144a2ed4f334617feaaab4</sha1hash> </response> HPP Response Below is a sample response with the new field highlighted with sample SRD value 'Sample123456789': [RESULT=00, AUTHCODE=12345, MESSAGE=[ test system ] Authorised, PASREF=14631546336115597, AVSPOSTCODERESULT=M, AVSADDRESSRESULT=M, CVNRESULT=M, ACCOUNT=internet, MERCHANT_ID=MerchantId, ORDER_ID=N6qsk4kYRZihmPrTXWYS6g, TIMESTAMP=20180613113227, AMOUNT=1001, CARD_PAYMENT_BUTTON=Pay Invoice, MERCHANT_RESPONSE_URL=https://www.example.com/responseUrl, HPP_LANG=GB, BILLING_CODE=59|123, BILLING_CO=GB, SHIPPING_CODE=50001|Apartment 852, SHIPPING_CO=US, COMMENT1=Mobile Channel, ECI=5 CAVV=AAACBUGDZYYYIgGFGYNlAAAAAAA=, XID=vJ9NXpFueXsAqeb4iAbJJbe+66s=, SRD=Sample123456789, SHA1HASH=8ab81d4437e24a88a08cffb51c15151846bd7b61]

[feemish]

Hi Josh,

With the deadlines looming I am sure you can understand that those of us using PSPs are getting a little nervous.

I wonder what you mean by the statement that you will be making an announcement that 'informs all our customers'.

If the information is a guide to how to update our code so that it meets the new requirements then all good.

However if the relevant information is something else, perhaps that you will not support some PSPs going forward, or that we are on our own to sort out the upgrade, then we'd really like to know as soon as possible so we can make arrangements or changes.

Would you be able to give us a clear indication of what the path forward will be asap?

Thanks.

[feemish]

I had a conversation with Realex/Globalpay ecomm support person who told me that in regards to their system the changes were simple and minimal. Can any developers comment?

I was told that for the purposes of HPP integration, what needs to be done are that several new mandatory fields must be sent as part of the POST data.

But as far as I can see most of these are already being collected at checkout if not being sent. So perhaps it is only a very small change that is needed?

Mandatory Fields:
<input type="hidden" name="HPP_VERSION" value="2">
<input type="hidden" name="HPP_CUSTOMER_EMAIL" value="test@example.com">
<input type="hidden" name="HPP_BILLING_STREET1" value="Flat 123">
<input type="hidden" name="HPP_BILLING_STREET2" value="House 456">
<input type="hidden" name="HPP_BILLING_STREET3" value="Unit 4">
<input type="hidden" name="HPP_BILLING_CITY" value="Halifax">
<input type="hidden" name="HPP_BILLING_POSTALCODE" value="W5 9HR">
<input type="hidden" name="HPP_BILLING_COUNTRY" value="826">

and at least one of those

<input type="hidden" name="HPP_CUSTOMER_PHONENUMBER_MOBILE" value="44|789456123">
<input type="hidden" name="HPP_CUSTOMER_PHONENUMBER_HOME" value="44|789456123">
<input type="hidden" name="HPP_CUSTOMER_PHONENUMBER_WORK" value="44|789456123">

[ukjrav1]

Morning, can we please have an update regarding this as the deadline is near. My company uses Sellerdeck Business 2013 (v12) with Global Payments (formerly Global Iris) as our PSP. Thanks.

[feemish]

Would Sellerdeck please give us an update on this? The deadline is fast approaching. Please at least tell us in good time if you are going to provide a solution for the upgrade.. if you are not then it would be only fair if you gave us enough time to actually attempt to sort it out ourselves.

[Josh Barling]

Hi All,

I have drafted the full response for PSD2, 3D Secure v2 and other announcements related to payment gateways with Sellerdeck. We are keen to provide answers in all scenarios (including, different versions, other payment gateways etc).

I'm just updating our website with further content so its all available when you start to investigate answers and options (beyond just Realex).

I'm hoping to have that ready to send out by the beginning of next week.

Thanks

[feemish]

OK Thanks Josh

[Josh Barling]

Hi All,

Thank you for your patience with us on this thread.

We've created the statements and will be sending communication to the userbase over the next week.

I wanted to share the content of our statements with this thread so that you have immediate access and also explain our position with Global Payments (Realex).

The page we have created for general information is: http://www.sellerdeck.co.uk/psd2/
The page we have created for information on our supported and recommended payment gateways is: https://www.sellerdeck.co.uk/support...ice-providers/

Global Payments has been helpful and engaged throughout the investigation. The discussions with their team indicated a project was required to bring the integration inline with recent Global Payments changes, including and beyond 3D Secure version 2. The results showed a small proportion of active users and a high number of development days.

As a result, we have decided to invest our development effort in other payment service providers which are more popular in the Sellerdeck userbase and we believe offer a better overall solution.

This will require a change in your payment method, which I appreciate isn't ideal. However, it is a simple change and can be easily completed within less than two weeks. Contact your merchant provider and request that your MID is setup to work with the new payment service provider, then give that MID to your new provider.

[feemish]

Wow Josh. 8 months since I asked the question about this, and you leave it to 4 weeks before the deadline to tell us you won't support the change. I think you probably knew this months ago.