дальше в query builder-е будет просто в when передаваться и если null, то ничего не сделается

в собственном правиле вы можете не только возвращаеть тру фолс, но и производить любые необходимые вам манипуляции.
убираете из валидатора in:1,2, добавляете свое правило. в нем проверяете что значение 1 или 2, в противном случае заменить на null и вернуть true
но это потом аукнется.
можно мидлвару повесить, которая будет делать то же самое.
если вы сетапите потом эти данные - можно написать свой set для них, и обрабатывать в нем.

последний помоему самый удобный в плане отлова багов

есть примеры оплаты через cloudpayments, можете скинуть?

а какие там примеры? точно так же как и везде, отправил запрос на оплату, редирект на платеж и ждешь коллбек от клауда о статусе оплаты

Если формированием запроса занимаетесь вы тогда для чего закладывать такой вариант работы, емли данные запроса не прошли проверку, значит с ними нельзя работать

с рекурретными платежами чуть геморойнее, но в целом тоже ничего сложного

угадал )

так вроде такие сервисы рекурентность сами мониторят
задача клиента уже просто эндпоинт сделать для принятия уведомлений о поступлении платежа

там можно настраивать платежи отличные от первого, переодичность и тд

Господа, нужна помощь, где я туплю? Глаз может замылило

я могу помочь пройти php на уровне разговорного

🥲

ждет формат даты с дефисом, а ты переслал с точками

Там англ нужен )🙂

Всем привет, работал кто в связке с Rapid Lei + Sttripe
либо же просто Rapid Lei
или уже на крайняк просто хоть кто то с Lei сталкивался?

Нужна помощч

та нет же, в ошибке собственно дата, которая на валидацию идет

а, точно

[$x,$y] = castomFunction();
что происходит?)