Why this is important

Thanx leverages proprietary integrations with Visa, Mastercard, and American express to allow consumers to earn rewards when they use a card associated with their accounts when they make qualifying purchases. This requires the customer to enter their card and acknowledge that it will synchronize their purchases at participating locations with their account to earn rewards (purchases at non-participating businesses are not shared with Thanx or our merchant partners). This in turn powers the CRM’s automated marketing and targeting tools as well as provides valuable analytics to the brand.

For non-ordering focused apps i.e. malls, retail, etc, card capture at signup is particularly crucial; this is a time you have the users focus and attention, and can highlight the values and incentives for enrolling their card. Our studies show that if a customer doesn’t enroll a card within 2 minutes of creating an account they are unlikely to add one later.

This document outlines adding cards during a signup flow, capturing cards for loyalty tracking when making an online digital purchase, the ability to add cards proactively within account settings, and the ability to manage cards (remove them, etc).

How Thanx does this

Card management page

Customers must be able browse to a screen that lists their cards in the app settings. On this screen they should be able to add more cards, as well as remove any card they have stored.

Note the legal text on the “add payment method screen”. This must be kept “as is” including the descriptor texts above. See Requirements section for full details.

Notice the camera icon in the card input field. Thanx API does not include this functionality, but we recommend you implement this functionality with a 3rd party such as Dyneti.

Checkout (ordering apps)

For applications that include ecommerce, the flow above allows the customer to both pay and enroll the card for reward tracking. This is by far the most efficient way to onboard consumers, as they are typing in their card for payment anyway. In our apps, we see a ~90% conversion rate of customers choosing to store the card for loyalty benefits when they pay.

If a customer already has a card enrolled (e.g. in the signup flow), they will not see this screen when they choose to pay with that known card.

One important nuance is that in this specific flow, errors that come back from enrolling a card for loyalty are not displayed when we build these screens; we don’t want to interrupt a consumer’s ability to make the purchase. The most common error that comes from enrolling a card for loyalty is that the card is already connected to a different consumer account, which typically means the consumer has another account under a different email address. Asking a customer to address that in the checkout flow would lose the purchase. In that scenario, our apps just accept payment and suppress the card enrollment error.

As noted above, it’s important that the screen you present are as close to identical to the designs above. While branding and layout can be adjusted, the wording of the text and buttons should not be altered.

Full flow below

How other merchants do this

Dig app

This is an example of how one of our partners (Dig) has laid out the card enrollment flow.

Requirements for implementation

These are requirements that we have negotiated with our card network partners. All card enrollment experiences must be approved by these partners to use the card linked APIs they provide. While you are free to design these experiences as you like, it may produce significant delays of certification. We recommend using the designs as we have presented them to ensure a speedy deployment of your application.

  • Legal text must be on any screen where you allow a customer to enter their card number and store for loyalty tracking. The legal copy may not be altered.
  • Button must say “Register card”
  • Legal text must be visible at all times on all devices supported
  • ToS and Privacy Policy must be obviously clickable (e.g. darker and underlined)
  • Must comply with standard accessibility guidelines in regards to color contrast and legibility (see: https://accessible-colors.com/)

Card Registration Screen Variants

Ordering app signup

Loyalty app signup

Ordering app add payment method

Loyalty app add payment method

Design tips from our team

  • Fonts & colors: check font size and color contrast against accessibility standards. To check the optimal contrast for type foreground/background color you can use this tool https://accessible-colors.com/
  • Buttons: should be a min height of 40px (Apple recommends 44px) for a reasonable tap area. On screens with two buttons (ordering enrollment) both must be the same size, though they can differ in visual weight (e.g. color, outline, etc).
  • Forms and inputs: automatically pre-fill values in fields where possible, and let users know which fields are required (or just which are optional), and for longer forms break them down into simple steps (e.g. signup flows are better as a series of input screens).
  • Error handling: be as explicit as possible so users understand why they ran into an error, and give them a means to correct or move forward from there. Include support links in critical flows, where users may need further assistance. See our API docs for how to handle error responses.

Common use cases, questions and errors

Error: “This card is already associated with another account”

Why this happens:

  1. When a card is on file for a consumer, it cannot be registered for loyalty benefits for another account. That would allow two customers to get credit for the same purchase. So Mr and Mrs Smith each have an account, and they both have the same card number. Mr Smith adds it first, and then Mrs Smith tries. She will get an error that the card is already associated with another account. This prevents fraud (intentional or otherwise).
  2. A more common use case is Mr Smith has two email addresses, and he’s created an account on our platform with one and associated that card, and then he downloads Dig and creates an account with a different email address. He’ll get the same error. Our support team can help the customer resolve the issue by merging accounts.

Additional cases

Now, here’s the nuance. In our apps, when we’re taking payment for digital ordering, and the customer selects “save card and earn rewards” we attempt to tokenize the card with the ordering provider AND with the card network (Visa et. al.). If Visa responds “this card is already in use” we don’t do anything. We don’t tell the customer or anything. We just take their card and run the payment.

Introducing the error that the card can’t earn in-store loyalty on that screen just loses the sale and produces customer frustration. The duplicate account issue takes time to resolve. The best call is to just get the customer their food and accept that their card did not successfully enroll for in-store loyalty.

Our recommendation here is that the merchant ignore that error from us when adding payment, and that the screen that lists cards enrolled for loyalty show that card as not enrolled for benefits should the consumer go to that screen specifically.