Продажба на билети онлайн: кога плащането позволява издаване на билет

Разделете резервацията от продажбата

Първо определете как се резервира място или ограничен капацитет и колко дълго се пази. Създадена поръчка не означава платен билет. Резервацията може да изтече, докато платежният опит още е в процес, затова трябва да имате правило за такъв късен резултат.

Например последните две места са резервирани от клиент, който плаща бавно. Ако системата ги освободи и продаде на друг, а първото плащане после успее, възниква конфликт. Опишете как екипът ще го разреши, преди да пуснете ограничена продажба.

Планиран продукт за билети

Проверявайте сумата и съдържанието на поръчката

Пазете на сървъра броя билети, категорията, приложената отстъпка, таксите и валутата. Не позволявайте клиентският браузър да определя крайната сума без проверка. При промяна на избраните места платежната заявка трябва да съответства на актуалната поръчка.

За групови покупки уточнете дали получателят на всеки билет е различен от платеца. Това е въпрос на продуктова логика, а не причина да поставяте личните данни на всички посетители в платежния URL. Изпращайте към доставчика само необходимите стойности и безопасни референции.

Платежни известия

Издавайте след надеждно потвърждение

Използвайте проверено сървърно известие или подходящо получаване на статуса от доставчика. Сравнете операцията с правилната поръчка, сума и валута. Страница за благодарност не трябва сама да издава билет, защото клиентът може да я отвори без валидно окончателно плащане.

При затворен браузър успешното плащане пак трябва да доведе до правилното изпълнение. Обработката не бива да зависи от това дали клиентът се е върнал от платежния сайт. Поддържайте запис кога резултатът е получен и кога билетът реално е създаден.

Предотвратете двойно издаване

Платежният webhook може да се повтори, а служител може да натисне повторно изпращане. Разделете създаването на един билет от изпращането на съобщение с вече съществуващия билет. Повторната доставка не трябва да генерира нов валиден пропуск със самостоятелна стойност.

За една поръчка използвайте устойчива идентификация и атомарна промяна на състоянието. Ако обработката прекъсне между плащането и изпращането на имейла, системата трябва да може да продължи безопасно. Изтриването на следите и ново изпълнение от начало често създава дубликати.

Опишете отменяне и възстановяване

Рифъндът на плащането и обезсилването на билета са свързани, но различни операции. Уточнете кога билетът престава да е валиден и как се обработва частично възстановяване на групова поръчка. Екипът трябва да вижда кои конкретни билети са засегнати.

Не обещавайте универсална политика за връщане или срок за получаване на средствата. Те зависят от условията на събитието, приложимите правила и платежния метод. Клиентското съобщение трябва да отразява реалния статус, а не само факта, че служител е започнал процедурата.

Проверете готовността на всички части

Билетният продукт на OrsunPay трябва да се разглежда според текущата му наличност. Ако е Soon, не приемайте, че системата вече включва места, сканиране на входа и автоматична доставка. Платежна интеграция сама по себе си не заменя цялата платформа за събития.

Преди старт проверете успешна продажба, забавено плащане, изтекла резервация, повторено известие и частичен рифънд. Определете кой ще следи несъответствията в деня на събитието. Така екипът ще има конкретен план и при най-неудобния случай, а не само красив успешен демонстрационен поток.

Източници

• Stripe Checkout
• Stripe Webhooks