Подготовка на Вашите системи за Shop Cash

Преди да стартирате работни процеси в Shop Cash със системи на трети страни, потвърдете следните изисквания:

• Вашите ERP, OMS, системи за обработка и доставка, счетоводство и връщане могат да приемат повече от един начин на плащане за една поръчка.
• shop_cash е съпоставен като начин на плащане, когато са налични стойности от шлюза.
• Shop Cash не се третира като отстъпка, подаръчна карта или кредит в магазина.
• Стойността на оторизацията се съхранява като непрозрачен низ с променлива дължина от поне 1024 знака. Ако е възможно, използвайте неограничено текстово поле.
• Прихващанията, анулиранията и възстановяванията на суми се идентифицират чрез идентификатор на транзакция, а не чрез стойността на оторизацията. Операциите за прихващане и анулиране в Admin API използват parentTransactionId, а операциите за възстановяване на сума използват parentId.
• Системите ви не анализират, декодират, нормализират, хешират или съкращават стойностите за оторизация на Shop Cash.
• Системите ви могат да обработват групирани изплащания, при които един ред shop_cash_credit може да представлява множество поръчки.
• Работният ви процес за съгласуване не предполага, че една поръчка е равна на един ред за изплащане.
• Работният ви процес за съгласуване може да обработва частта от Shop Cash и частта от плащане с карта или плащане на вноски в Shop Pay, които се уреждат в различни изплащания.
• Работният ви процес за възстановяване на суми може да обработва частични възстановявания на суми към карта или плащане на вноски в Shop Pay и Shop Cash.
• Приложенията за възстановяване на суми могат да възстановят транзакцията за прихващане на Shop Cash, а не транзакцията за оторизация.
• Ако сте провеждали Shop Campaigns преди януари 2026 г., финансовият ви работен процес обработва историческите редове shop_cash_campaign_billing_debit и свързаните с тях редове за таксуване на кампании отделно от приходите от поръчки. Разходите за кампании от януари 2026 г. нататък се начисляват към обобщената ви месечна фактура в Shopify вместо това.

Тестването на Shop Cash има ограничения, тъй като Shop Cash зависи от акаунти на купувачи в Shop, салда в Shop Cash, Shopify Payments и инфраструктурата за сетълмент на Shop Cash.

Най-надеждният начин за цялостно валидиране на корпоративна интеграция е да направите производствена поръчка на ниска стойност през Shop и след това да възстановите сумата за нея. Това създава транзакции за поръчки, наподобяващи производствените, данни за прихващане, активност по изплащане, транзакции за възстановяване на суми и дебитна активност по възстановяване на суми, които преминават през администраторския панел на Shopify, данните в Admin API, експортиранията на изплащания и данните в API за изплащания.

Магазините в режим на разработка могат да помогнат за валидиране на някои форми на полета в API и логика на съпоставяне, но не изпълняват надеждно пълния процес на плащане, иницииран от Shop, салдото на купувача и потока на сетълмент. Тестовият режим и фиктивният шлюз (Bogus) не създават редове за изплащане на Shop Cash, наподобяващи производствените, тъй като не използват реален поток на сетълмент в Shopify Payments.

Обикновено можете да тествате следните работни процеси чрез производствена поръчка на ниска стойност, инициирана от Shop:

• Приемане на поръчка за поръчка с няколко начина на плащане, която включва Shop Cash и Shop Pay или плащане на вноски в Shop Pay.
• Съпоставяне на ERP или OMS за shop_cash.
• Съхраняване на пълната стойност на оторизацията на Shop Cash.
• Пълни и частични възстановявания на суми по поръчката.
• Приемане на активността по изплащане shop_cash_refund_debit.
• Съгласуване на изплащанията за кредити в Shop Cash.
• Поведение при предварителна поръчка или прихващане при обработка и доставка, ако вашият магазин използва отложено прихващане.
• Обработка от приложение за връщане за поръчки с повече от един начин на плащане.

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

Свържете се с екипа на Shopify за поддръжка, ако имате нужда от помощ за някой от следните сценарии:

• Преглед на наличността на Shop Cash за пазар, за който се изпълнява план за въвеждане.
• Разследване на неуспешно прихващане или възстановяване на сума в Shop Cash.
• Разследване на липсваща транзакция за изплащане в Shop Cash след нормалния ви ритъм на изплащане плюс един допълнителен цикъл на изплащане.
• Проверка дали анулирана или изтекла оторизация на Shop Cash може да бъде оторизирана отново.
• Планиране на стартиране за сложен работен процес, свързан с ERP, OMS, предварителна поръчка или обработка и доставка.

Преди да увеличите обема на поръчките със Shop Cash, изпълнете следните проверки:

• Съпоставянето на начините на плащане в ERP и OMS е внедрено и потвърдено за shop_cash.
• Примерна поръчка със Shop Cash е приета от край до край, включително транзакциите за оторизация и прихващане.
• Примерен кредит за изплащане в Shop Cash е съгласуван с първоначалната поръчка или поръчки.
• Примерно възстановяване на сума в Shop Cash е обработено и съгласувано с дебита за възстановяване.
• Групираните редове за изплащане в Shop Cash се поддържат или имат процес за ръчно съгласуване.
• Разпределението на частичното възстановяване на сума е разбрано от екипите ви за поддръжка и финанси.
• Поведението при предварителна поръчка, ръчно прихващане и прихващане при обработка и доставка е валидирано, ако е приложимо.
• Приложенията за връщане могат да идентифицират и да възстановят сумата за правилната транзакция за прихващане в Shop Cash.
• Екипите за поддръжка и финанси знаят разликата между салдо в Shop Cash на клиент, оферти в Shop и активност по таксуване в Shop Campaigns.

За изисквания относно API и данни за поръчки вижте Данни за поръчки със Shop Cash и интеграции на трети страни. За изисквания относно изплащания вижте Съгласуване на изплащания в Shop Cash.