Плащане с карта в WooCommerce: проверки преди пускане

Проверете съвместимостта предварително

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

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

Приставки за електронни магазини

Дръжте сумата на сървъра

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

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

Хоствана страница за плащане

Съпоставете статусите на поръчката

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

Клиентът може да затвори страницата след успешно плащане. Магазинът трябва да получи сървърното известие и без отворен браузър. Обратно, отворена страница за благодарност не трябва да позволява изпълнение на поръчка, за която няма валиден платежен резултат.

Предвидете повторно натискане и забавяне

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

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

Прегледайте рифънда и отчетите

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

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

Пускайте само наличната функционалност

Страницата на OrsunPay за e-commerce приставки описва продуктова посока и текуща наличност. Ако дадена приставка е означена като Soon, не я третирайте като готово разширение за инсталиране. Потвърдете реалния начин на интеграция и необходимата разработка за вашия магазин.

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

Източници

• Stripe Checkout
• Stripe Webhooks