Sleva v bráně se aplikuje na jiný základ než sleva v objednávce

import { Aside } from ‘@astrojs/starlight/components’;

Slevu posílej do brány jako FIXNÍ částku (amount_off) rovnou hodnotě uložené na objednávce, ne jako procento — procenta si brána spočítá z vlastního základu, který se tvému nemusí rovnat.

Symptom

U objednávek s věrnostní slevou a placenou dopravou se stržená částka liší od total objednávky o malé částky (procento z dopravy). Účetnictví/faktura zní na jinou sumu, než přišla z brány. Bez aktivní rekonciliace částek si toho nikdo nevšimne — webhook event „payment completed” nikdo neporovnává s objednávkou.

Root cause

Aplikace počítá: total = (zboží − sleva%) + doprava — sleva jen ze zboží.

Do brány ale poslala procentní kupon na celou checkout session:

const coupon = await gateway.coupons.create({ percent_off: discountPercent, duration: 'once' });
session = await gateway.checkout.sessions.create({
  line_items: [...goods, shippingLine],   // doprava je line item
  discounts: [{ coupon: coupon.id }],     // procento se vztáhne i na ni
});

Brána slevu spočítá ze SVÉHO základu (všechny line items včetně dopravy) → strhne méně, než zní objednávka. Druhá platební cesta (přímý PaymentIntent na total) se přitom chovala správně → dvě cesty, dvě částky.

Fix

const coupon = await gateway.coupons.create({
  amount_off: discountAmountStoredOnOrder * 100,  // přesně to, co je na objednávce
  currency: 'czk',
  duration: 'once',
});

Plus rekonciliace ve webhoonku: porovnat amount_total eventu s totalem objednávky (tolerance na zaokrouhlení) a nesoulad hlasitě logovat.

Jak se tomu vyvarovat v jiných systémech

• Detection: SQL nad zaplacenými objednávkami se slevou: porovnej captured amount z brány s total (pokud ukládáš), nebo jednorázový export z dashboardu brány vs. DB. Grep percent_off v kódu, kde session obsahuje i non-goods line items (doprava, poplatky).
• Anti-pattern: procentní sleva předaná bráně, zatímco lokální výpočet ji aplikuje na užší základ; více platebních cest s vlastním výpočtem částky.
• Lepší přístup: jediná funkce vracející total + discountAmount pro VŠECHNY platební cesty; bráně posílat hotové částky; webhook vždy rekonciluje částku eventu proti objednávce.

Sister bugs / související

Obecný vzor „dva systémy počítají tutéž částku každý po svém”: DPH zaokrouhlení per-line vs. per-total, měnové konverze s různým kurzem na FE/BE/e-mailu. Řešení vždy stejné — jeden výpočet, druhá strana dostává výsledek.