question

mrlim avatar image
mrlim asked ·

iFrame and high non-qualifying transaction rates

Recently did an integration for a new Clover/First Data customer.


After implementing an iFrame integration, the merchant noticed a very high number of "non-qualifying transactions," charged at a much higher rate, on their statement the next month.


They suspect transactions done through the iFrame integration are being categorized as "non-qualifying transactions" resulting in the higher rates.


Has anyone else seen this as well?


The iFrame doesn't seem to capture any other info than the card number, expiration, CVV and postal code.


Trying to find more information about "non-qualifying transactions," it seems like if you don't collect the cardholder name, address, etc, a transaction could be flagged as "non-qualifying" and charged a higher fee?


There's also a reference to 3D Secure requirements - does the Clover API support 3D Secure through the iFrame? Or at all?


Needless to say, I have a pretty unhappy customer right now... =(


Bottom line, how do we get this customer's transactions to stop being "non-qualifying" using the iFrame integration?

e-commerce api
10 |2000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

ecommteam avatar image
ecommteam answered ·

Unfortunately we have no insight into a merchants agreed upon rate structure with their processor. I'd recommend finding out if the merchant is on tiered pricing. That structure is typically not advisable if there is an expectation of high volumes of card-not-present transactions since the low qualified rate is not obtainable and the resulting transactions are bundled in mid or non-qualified tiers.


If they are on a tiered structure I'd recommend they negotiate structure better suited for their use. An interchange plus rate structure would likely provide the greatest cost savings , but can sometimes be hard to decipher since the resulting monthly statement is dozens of pages. A more popular structure for its simplicity is a flat rate model. This should allow the merchant to pay one rate for card-present transactions through a clover device and another rate for online transactions through conduits like the iframe.


If they are not on tiered pricing then i'd recommend the merchant reach out to support to investigate what a "non-qualifying transaction" is.


As for 3DS, it is on our radar, and while its not widely used in the US yet our peers in the EU require it or similar technologies. Therefore to better support international merchants and provide improved fraud tools we do plan to add support. I'm not able to share a timeline at this point.

10 |2000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

ecommteam avatar image
ecommteam answered ·

Thank you for doing the legwork to try to help this merchant. Discount rate w/ multiple tiers is the same as tier pricing.

The operating guide you shared is from the UK where 3DS is absolutely a requirement, so I'm not sure if it's completely applicable to the US market.

It does seem that if a merchant is enrolled in a tiered pricing scheme that ecomm api transactions will be considered non-qualified.

The simple answer is to have the merchant ask to change their pricing scheme to a more simplified and transparent scheme like swipe/non-swipe flat rate. Thats what Clover.com and our peers like Square and Stripe provide. I'm just not sure who they need to contact to do that, might need support to escalate them to a higher tier or a sales org. Its unfortunately a bit of a blackbox to me. Changing gateways seems like a sledgehammer approach to the problem. Can you share the merchant info by emailing me at vtbeta@clover.com ?


This is a good explainer on the wonderful world of processing rates...

https://www.merchantmaverick.com/the-complete-guide-to-credit-card-processing-rates-and-fees/

10 |2000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

mrlim avatar image
mrlim answered ·

I followed up with the Merchant again, and was able to get a bit more info.


They're in Canada, so chip/PIN and 3D Secure is commonplace, I believe.


Other than the non-qualifying transactions, they're very happy with their rates, and don't want to change their pricing agreement. They do a combination of in-person and ecommerce transactions, so saving on the qualifying in-person transactions is important.


They're leaning towards changing to a different gateway that supports 3D Secure, as this will result in qualifying transactions on their ecommerce plaform too.


Until Clover eCommerce API supports 3D Secure, it seems it might be worth them making the switch.


It is a bit of a sledghammer, but I can't really disagree with the merchant if it results in lower fees this way.


Hopefully Clover can implement 3D Secure in the near future!

10 |2000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

mrlim avatar image
mrlim answered ·

Thanks for the response!


"If they are not on tiered pricing then i'd recommend the merchant reach out to support to investigate what a "non-qualifying transaction" is. "


Good advice - They are not on tiered pricing, but a discount (flat) rate. The only exceptions to their discount rate are these "non-qualifying" transactions. Merchant was referred to this:
https://www.firstdata.com/downloads/pdf/operating-guide.pdf
Page 26 - eCommerce section says:


"Qualifying transactions are 3D secure enabled e-commerce transactions submitted for processing within two business days of the transaction."


Since there is no 3D Secure support yet...

... is it not possible for the Clover eCommerce API to process a qualifying transaction at all?

... thus all transactions will be charged at the higher non-qualifying rate?


Honestly, that doesn't quite seem right, but hopefully someone here might be able to confirm or clarify this?


Coincidentally (or not?), the merchant was given an option to switch to a different payment gateway that does provide 3D Secure, at an additional cost. Working the numbers, it could make sense to switch due to the difference in qualifying vs non-qualifying rates. I think they'd prefer to stay with the Clover eCommerce API, provided they can figure out how to get the transactions to qualify.


When the merchant asked for more details about how transactions are classified as qualifying or non-qualifying, support mentioned vaguely that if "not enough information is captured, like name, address, etc" the transaction could be considered non-qualifying. But they said to contact Clover as "every system does things a bit differently" so we should check with them...


They might just be trying to pass the buck, but still holding out hope someone here might be able to shed some light on this.


I hope it's not just "all Clover API transactions are non-qualifying right now" and that we're just missing something simple...

10 |2000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Welcome to the
Clover Developer Community