Tester les codes promo de l’inscription au paiement

Pourquoi les parcours de codes promo cassent sans bruit

• L’e-mail arrive en retard. Les e-mails d’offre passent souvent par un outil marketing planifié, quelques minutes après l’inscription, et personne ne remarque quand cela devient une heure.
• Le code fonctionne trop souvent. Un code à usage unique accepté deux fois, ou après sa date de fin, coûte de l’argent à chaque fois.
• Une personne, plusieurs comptes. S’inscrire à nouveau en tant que name+promo1@ donne une deuxième offre de bienvenue dans beaucoup d’applications. Voir abus des offres de bienvenue.
• Les détails sont faux. L’e-mail annonce 20 % et le paiement en donne 10 %, ou l’e-mail ne dit jamais quand l’offre se termine. « Se termine dimanche » et « aujourd’hui seulement » comptent comme date de fin, à partir du jour d’arrivée de l’e-mail.

Comment Proxy Mail QA vous aide

1. Inscrivez-vous à l’offre sur votre site de staging avec une nouvelle adresse.
2. Consultez le code promo sur la page Comptes et dans la boîte de réception : le code avec Copier, sa remise (« 20 % de réduction »), sa date de fin et le délai d’arrivée après la création de l’adresse. Une fois la date de fin passée, il affiche « Expiré » et reste copiable, pour tester que le paiement le refuse.
3. Appliquez-le au paiement avec des paiements de test, puis enregistrez le résultat dans la boîte de réception : Accepté, Refusé ou une erreur, avec le message affiché par votre application.
4. Lisez le verdict. Un code promo accepté après sa date de fin, accepté deux fois alors qu’il est à usage unique, ou accepté pour une offre déjà obtenue par la même personne échoue. Une erreur donne un avertissement.

À vérifier

• Le code promo arrive dans le délai promis, par exemple 5 minutes après l’inscription.
• La remise au paiement correspond à l’e-mail.
• Un code à usage unique est refusé la deuxième fois, avec un message clair.
• Un code expiré est refusé.
• L’e-mail indique quand l’offre se termine et contient un lien de désabonnement : les offres sont du marketing.

Dans un test

const submitted = new Date();
await page.getByRole('button', { name: 'Get 20% off' }).click();

// Offers often take minutes: this waits up to 10.
const coupon = await qa.waitForCode(address, { type: 'coupon', since: submitted, timeout: 600 });
expect(coupon.discount).toBe('20% off');
expect(coupon.after_seconds).toBeLessThan(300);

await page.getByLabel('Promo code').fill(coupon.value);
await page.getByRole('button', { name: 'Apply' }).click();
const first = await qa.recordCouponResult(address, 'accepted', { oneTime: true });
expect(first.check?.status).toBe('pass');

// The same code again should be refused.
await page.getByLabel('Promo code').fill(coupon.value);
await page.getByRole('button', { name: 'Apply' }).click();
const again = await qa.recordCouponResult(address, 'rejected', { message: await page.getByRole('alert').innerText() });
expect(again.check?.status).not.toBe('fail');

Les agents connectés au MCP server obtiennent la même chose avec wait_for_code (kind coupon) et record_coupon_result, et le prompt test_coupon_checkout déroule tout le parcours en staging.