Which coupon did that checkout apply?

A customer says the discount did not apply, or says they were charged the full amount after typing a code. Tonight, three proofs, in a console you administer. Name the coupon that checkout applied: the coupon id, the percent or the amount taken off, and the code that points at that coupon. If the session stored no discount, write that, including a zero amount and a null switch, and do not invent a code to fill the hole. Show a different code whose coupon id is not this one. Show another account's list that does not contain this coupon. If any of the three needs the person who wired checkout, you have not named the coupon. You have a banner and a guess.

This is the coupon on one checkout. It is not the product. Which product did that price sell? is the product id and the unit amount on a price. A price can be right while no coupon is stored, and a coupon can be valid while the price it was meant to touch is a different object. It is not the session. Which session did that checkout open? is the session id and the status. A session can be open while the discount field is empty. It is not the figure they were shown. Show the price they accepted is the amount on the screen at acceptance. A screen can print a percent the session does not store. It is not the label on an issue, and it is not the file on a message. Those are different objects, and they are not this id.

None of what follows is a rate for this product, and none of it is legal advice. The fields below are one processor's current description of a coupon, of a promotion code, and of a checkout session, and the samples are not the same object. The counts below that are a 2025 paper about other companies' pricing pages. A percent on an example is not a census of your buyers. A paper that says its own model does not represent discounts cannot name the coupon on the session you opened tonight. They do tell you which numbers people mix up when they try to sound precise about a code they have not opened.

Stripe's coupon object sample and Stripe's create-coupon response print the same id and do not print the same duration. The id is jMT0WJUD. 8 characters. percent_off is 25.5 on both. created is 1678037688 on both. amount_off is null on both. currency is null on both. name is null on both. times_redeemed is 0. valid is true. livemode is false, so the object is an example, not a live discount on your account. The object page sets duration to repeating and duration_in_months to 3. The create response sets duration to forever and does not print duration_in_months at all. The create request that the page shows sends duration=forever and percent_off=25.5, which matches the create response and does not match the object sample. forever is not repeating. 3 is not a field the create response stored. Do not paste the object page's 3 onto the create response because the id matches (Stripe, The Coupon object, and Create a coupon).

The create page also says what a name and a percent are allowed to be, and the sample uses neither maximum. The name maximum length is 40 characters. The sample name is null. 8 on the id is not 40, and null is not a name you may invent from the id. percent_off must be a positive float larger than 0 and smaller or equal to 100. 25.5 is inside that range. It is not the top of the range. The object page's own sentence says a coupon with percent_off of 50 will make a 100 dollar invoice 50 dollars. 50 is not 25.5. 100 is not the 2198 on the checkout sample below. A sentence about a different percent is not the field on this object. The create page's version header on the sample request is 2026-10-28.endive. 17 characters. A version string is not a coupon id.

The same create page explains amount_off with two invoices, and it does not print the division a reader needs. It says an invoice with a subtotal of 100 USD will have a final total of 0 USD if a coupon with an amount_off of 20000 is applied, and an invoice with a subtotal of 300 USD will have a final total of 100 USD if a coupon with an amount_off of 20000 is applied. 20000 is not 100. 20000 divided by 100 is 200. 300 minus 200 is 100, which matches the second sentence only after that division. The page does not print the division. The first sentence's 0 is what you get if a discount larger than the subtotal is floored, and the page does not say the word cents. The coupon sample you were just looking at has amount_off null, not 20000. Do not copy 20000 onto jMT0WJUD because both pages were open. A null amount is not a percent, and a percent of 25.5 is not an amount_off.

The promotion code is a second sample, and its coupon is not jMT0WJUD. The code id is promo_1MiM6KLkdIwHu7ixrIaX4wgn. 30 characters. 30 is not 8. The customer-facing code is A1H1Q1MG. 8 characters, the same length as the coupon id, and not the same string. promotion.type is coupon. promotion.coupon is nVJYDOag. 8 characters again. nVJYDOag is not jMT0WJUD. active is true. The page says a promotion code is only active if the coupon is also valid, so true on the code is not a substitute for opening the coupon. times_redeemed is 0, the same zero as the coupon sample, on a different object. customer is null. max_redemptions is null. created is 1678040164. The coupon created value is 1678037688. The difference is 2476 seconds. 41 times 60 is 2460, and the remainder is 16, so the gap is 41 minutes and 16 seconds. It is not 3 months, and it is not forever. Two examples created inside the same hour are not one live redemption (Stripe, The Promotion Code object).

The checkout session sample is a third object, and it does not name either coupon. The id is cs_test_a11YYufWQzNY63zpQ6QSNRQhkUpVph4WRmzW0zWJO2znZKdVujZ0N0S22u. 66 characters. 66 is not 8, and it is not 30. amount_subtotal is 2198. amount_total is 2198. total_details.amount_discount is 0. amount_shipping is 0. amount_tax is 0. 0 plus 0 plus 0 is 0, and 2198 minus 0 is 2198, so the arithmetic inside the sample agrees with itself and still contains no coupon id. allow_promotion_codes is null. Null is not true. The attribute list says discounts is the list of coupons and promotion codes attached to the session. The sample JSON does not include that list. Do not invent a discounts array because the attribute exists. payment_status is unpaid. status is open. mode is payment. unpaid is not a coupon. 2198 times 25.5 divided by 100 is 560.49. 560.49 is not an integer, and it is not 0. Do not apply the coupon sample's percent to the session sample's total and call the result this checkout (Stripe, The Checkout Session object).

The session and the coupon were not created at the same second, and the session's own expiry is a different gap again. Session created is 1679600215. Coupon created is 1678037688. The difference is 1562527 seconds. 18 times 86400 is 1555200, and the remainder is 7327. 7327 is 2 hours, 2 minutes, and 7 seconds. The gap is 18 days, 2 hours, 2 minutes, and 7 seconds. It is not 3 months. It is not the 41 minutes between the coupon and the promotion code. expires_at is 1679686615. 1679686615 minus 1679600215 is 86400, which is 24 hours exactly. 24 hours is not 5 years, which is the create page's limit on how far in the future redeem_by may be set. The coupon sample's redeem_by is null. A null redeem-by is not a 24-hour session expiry, and a session expiry is not a coupon. customer is null on the session as well. A null customer is not a code.

The study people reach for when they want a count of pricing pages is a different document, and it says discounts are outside what it represented. Alejandro García-Fernández, José Antonio Parejo, Pablo Trinidad, and Antonio Ruiz-Cortés, at the Universidad de Sevilla, analyze machine-oriented pricing models. This is not their 2024 specification paper. The dataset here is 162 real-world pricings from 30 services over five years. They report inconsistencies in 35 of the 162, and they print 21.6%. 35 divided by 162 is 0.21605, which rounds to the 21.6% they print. 21.6 is not 25.5. The four buckets they name are 25 linked feature mismatches, 8 incorrect feature definitions, 1 temporal error, and 1 pricing without specific prices. 25 plus 8 plus 1 plus 1 is 35. That addition matches. They say 34 of the 35 came from the manual move off the web page, and that they corrected those 34. 35 minus 34 is 1. The page does not print 97.1, which is what 34 divided by 35 would be, times 100. Do not invent the percentage. They also say the Pricing2Yaml serialization has inherent limits on bundled offerings or discounts. A paper that sets discounts aside is not a coupon id (García-Fernández, Parejo, Trinidad, and Ruiz-Cortés, Automated Analysis of Pricings in SaaS-based Information Systems).

The same paper's other counts are a different scale from a checkout total. A synthetic set has 20 pricing models with seeded errors, and the solver missed 6. 6 divided by 20 is 0.3. The page does not print 30%. Salesforce's November 2019 pricing, they say, offered up to 10 configurations, and the July 2024 version allowed for over 12,000. 10 is not 12,000. The page does not print 1,200 as a ratio of those two. They propose 7 analysis operations. 7 is not 35, and 7 is not duration_in_months 3. Table 1's caption says each row is snapshots, features, plans, add-ons, and configuration-space size, for 2024. Tableau is 6, 41, 3, 7, 48. 3 plus 7 is 10, which is not 48. Dropbox is 4, 82, 4, 0, 4. The add-on cell is 0. The configuration cell equals the snapshot cell and is not 82. ClickUp is 6, 135, 4, 2, 13. 4 plus 2 is 6, which equals the snapshot count and is not 13. 135 is not 13. None of these cells is jMT0WJUD, and none of them is amount_discount 0.

Do the three proofs on one real session, in the console that actually holds it. First, the binding. Copy the session id, the coupon id, and the code. If amount_discount is 0 and allow_promotion_codes is null and the discounts list is absent, write that. Do not infer jMT0WJUD because a sample coupon prints it, and do not infer A1H1Q1MG because a sample code prints it. If the percent and the amount are both absent, write that neither was stored. A banner on the marketing site is not a field. Second, the other coupon. A different code, with a different coupon id, is not this one. nVJYDOag and jMT0WJUD are that shape on the sample pages, and they are still samples. A chart of 162 other companies is not that second code. If you cannot show a code that is not this coupon, you have a counter, not a record. Third, the other account. A list that belongs to someone else does not contain this coupon id. If the only list is a single shared table and you cannot say whose code it is, write that. A tenant you cannot name is the finding. It is not a reason to tell the buyer the coupon was 25.5 percent.

Three moves feel like the proof and are a second problem. Copying the percent off the homepage because the session's discount was embarrassing, and then describing the missing id as a cleanup. Quoting 21.6% because it looks precise, while the session you were asked about is one row, and the study that printed 21.6% had already said its model does not represent discounts. Asking a model which coupon was applied. The model will pick a plausible code. It will not open the session. A product id you have not kept, while the customer is arguing about the plan name, is which product did that price sell?. Opening that screen does not name the coupon.

The path is ordinary when an operator can open one merchant's wallet without opening the next merchant's wallet as the way to prove it. PayOrch is a payment orchestration dashboard: wallets, providers, merchants, fees, and fraud controls in one view. The shape that matters here is one merchant you can point at, in an account you administer, distinct from the next merchant. That case is not a coupon ledger. Nothing in the description is a headcount, a duration, or a result figure. If the only control on the screen shows a day's volume and will not name a coupon id, you do not have this proof. You have a chart.

There is a version of this afternoon where hiring the path is the wrong purchase. Nothing is for sale, because the product does not take money yet. You have no product. You are still choosing who will build, and the document in front of you is a term sheet. The criteria for that choice sit on the page written for a top SaaS development company. That page is criteria. It does not rank anyone, including us. The only fact in the room is a count of other companies' pricing pages. 35 is not your coupon, and 162 is not your coupon, and 25.5 on a sample is not your coupon. A customer has already seen another customer's payment. Naming an id does not close a leak. Or you wanted a lawyer to say whether a code is a contract. Hire the lawyer.

When the checkout is real and the console cannot name the coupon, the missing object is specific. An admin action, in an account you administer, that shows one session id and one coupon id or an explicit empty discount, shows a different code that is not that coupon, and shows another account's list without it. A startup software development company that expects this will have put that action next to the rest of the billing screen, before a stranger's complaint is the way you discover the vendor owns the code. One that needs a call in order for you to see which coupon is stored is telling you who holds the discount. If the first slice is a fixed capability, an AI integration sprint is the shape where the acceptance sentence can include the three proofs. If you do not yet know which system stores the session, a two-week AI readiness assessment maps the systems. The findings are yours. They are not a promise that a paper's count of pricings applies, and they are not 25.5.

The label an issue carried, and the file a message attached, are different objects: which label did that issue carry? and which file did that message attach?. Do not record either on this page. A label name is not a coupon id. A file id is not a promotion code. The quote a customer accepted is a different object: which quote did that customer accept?. Do not record it here. A quote id is not a coupon id. The intent a charge opened is a different object: which intent did that charge open?. Do not record it here. A payment intent id is not a coupon id.

Before you tell them the discount was applied, do the three proofs and write the id. Name the coupon, the percent or the amount, and the code, or write that the session stored no discount. Show a different code that is not that coupon. Show another account's list that does not hold it. Do not paste a sample percent onto a null, and do not ask a model which of the codes it was. A paper can tell you what it counted on other companies' pages, including the discounts it left out. The binding is the coupon you can defend.