Driekwart van de webshops laat je een opgeslagen kaart niet bijwerken, en dat kost herhaalaankopen
Baymard Institute testte hoe webshops omgaan met het bewerken van een opgeslagen betaalkaart in het account. De uitkomst: bij 75 procent van de geteste sites kon een opgeslagen kaartnummer niet worden bewerkt, en bij 8 procent kon er aan de kaartgegevens helemaal niets worden aangepast. Wie zijn kaart wil bijwerken moet hem dus verwijderen en opnieuw toevoegen.
Dat klinkt als een kleine ergernis in een hoek van de site waar bijna niemand komt. Het is precies andersom. De mensen die daar komen zijn je terugkerende klanten, en ze komen er omdat ze op het punt staan opnieuw te kopen.
Wat er in de tests gebeurde
Het gedrag dat Baymard observeerde is herkenbaar zodra je het leest. Deelnemers gingen ervan uit dat alles in hun profiel bewerkbaar was, want dat is het bij hun adres ook. Toen dat bij de kaart niet bleek te kunnen, gingen ze zoeken. Eén deelnemer besteedde meer dan twee minuten in het accountgedeelte op zoek naar een manier om alleen de vervaldatum aan te passen. Een andere verwijderde per ongeluk de kaart die ze net had toegevoegd, terwijl ze bezig was een opgeslagen kaart te vervangen.
Twee minuten zoeken naar een vervaldatum is in de context van een webshop een eeuwigheid. En het per ongeluk wissen van de nieuwe kaart is erger dan het klinkt, want die klant staat daarna verder van een aankoop af dan toen ze begon.
De reden is echt, de conclusie die eruit getrokken wordt niet
De achtergrond is PCI-DSS. Een webshop mag een volledig kaartnummer niet bewaren of tonen op een manier waarop het weer opgehaald kan worden. Bij een opgeslagen kaart werk je met een token, en een token laat zich niet bewerken zoals een postadres. Op infrastructuurniveau klopt het bezwaar dus.
De denkfout zit in de stap daarna: van een technische beperking een interfacebeperking maken. De keten verwijderen-en-opnieuw-aanmaken hoeft de klant helemaal niet te zien. Je kunt die twee handelingen achter één knop zetten die Bewerken heet, waarna het systeem intern het oude token intrekt en een nieuw token aanmaakt. Dat is precies wat Baymard aanbeveelt: een bewerkflow nabootsen door verwijderen en toevoegen samen te voegen in één taak die zich als bewerken presenteert. Aan de standaard verandert niets. De ervaring van de klant verandert volledig.
Er zit een detail in dat het waard is om aan je ontwikkelaar mee te geven. De volgorde is niet vrij. Maak eerst het nieuwe token aan, controleer dat het geldig is, en trek dan pas het oude in. Doe je het andersom, dan is precies het scenario mogelijk dat een testdeelnemer overkwam: het oude is weg, het nieuwe is mislukt, en de klant zit zonder betaalmiddel.
Waarom dit in Nederland en België zwaarder weegt dan je zou denken
Het gebruik van stored credentials groeit, en niet alleen bij abonnementen. Eenmaal-klikken is van een luxe een verwachting geworden, en elke webshop die herhaalaankoop belangrijk vindt bouwt aan een opgeslagen betaalmiddel. Daarmee groeit ook de groep die vroeg of laat tegen een verlopen of vervangen kaart aanloopt. Kaarten worden vervangen bij fraude, bij verlies, bij een overstap naar een andere bank. Dat is geen randgeval maar een jaarlijkse gebeurtenis voor een deel van je klantenbestand.
Dat de kaart in de Nederlandse online markt minder dominant is dan iDEAL maakt het niet minder relevant, want het mechanisme is niet aan de kaart gebonden. Elke opgeslagen betaalinstructie kent hetzelfde probleem zodra hij vernieuwd moet worden: een machtiging voor een terugkerende incasso, een wallet die aan een kaart hangt, een token dat je PSP voor je bewaart. Waar de kaart wel het zwaarst weegt is bij abonnementen en bij verkoop over de grens, en dat zijn precies de modellen waarin een klant meerdere keren terugkomt.
Het gevaarlijkste eraan is dat je het niet ziet
Bij een verlaten winkelwagen krijg je een signaal. Bij een geweigerde betaling krijg je een melding, en die komt in je PSP-rapportage terecht. Een klant die vastloopt op het bijwerken van zijn kaart produceert geen van beide. Er is geen event, geen foutcode, geen rij in een overzicht. Er is alleen een aankoop die niet heeft plaatsgevonden.
Daarom staat dit probleem zelden op een prioriteitenlijst. Het genereert geen cijfer dat iemand opmerkt. De enige manier om het te vinden is er zelf doorheen lopen: log in als klant, probeer de vervaldatum van een opgeslagen kaart te wijzigen, en tel hoeveel handelingen dat kost. Als het antwoord verwijderen-en-opnieuw-invoeren is, weet je genoeg.
Twee dingen die het onderzoek niet zegt
Baymard noemt in dit stuk niet hoeveel sites er in de test zaten, alleen de percentages. Behandel de 75 procent dus als een orde van grootte en niet als een precieze meting. Het punt staat er los van: de meerderheid van de webshops laat dit niet toe, en dat strookt met wat je vindt zodra je zelf een paar accounts naloopt.
Het onderzoek zegt ook niets over wat het je kost. Er is geen conversiecijfer aan gehangen, en dat kan ook niet, want de klanten die hierop afhaken laten geen spoor achter. Wat je wel zelf kunt uitrekenen is de bovengrens: neem het aantal klanten met een opgeslagen kaart, neem het deel daarvan waarvan de kaart dit jaar verloopt, en zet daar je gemiddelde orderwaarde en aankoopfrequentie naast. Dat getal is niet het verlies, want een deel van die mensen komt er wel doorheen. Het is wel het bedrag dat op het spel staat bij een schermpje dat nooit iemands aandacht krijgt.
Wat ik zou doen
Loop deze week één flow na in je eigen account: kaart bijwerken. Kijk of het als bewerken presenteert of als verwijderen. Als het het tweede is, is de ingreep een interfacekwestie en geen infrastructuurproject, en dat is doorgaans een kwestie van dagen en niet van kwartalen.
Neem er meteen twee dingen bij. Controleer of je klant een duidelijke melding krijgt als een opgeslagen kaart bijna verloopt, want dat verplaatst het probleem naar een moment waarop hij niet aan het kopen is. En kijk hoe je checkout reageert als de betaling met een opgeslagen kaart faalt: biedt hij dan meteen een andere methode aan, of eindigt de klant op een foutpagina. Dat laatste is dezelfde fout op een duurder moment.
Bron: baymard.com
