Зачем, по вашему, создавать новый объект платежа, если данные неизменны?
Зачем API ЮКассы обеспечивает идемпонентность запросов в 100% случаев?
Напомню, что вы не сможете обратиться к API ЮКассы без ключа. Никак.
Это ведь не такси, зачем это им? По вашей логике, это функционал поверх необходимого.
Требование такое, чтобы по одному и тому же номеру договора, платеж может быть только один.
Это годами устоялось, клиент привык к такому поведению и осознанно не желает это менять.
Привык, т.к. основной метод приема платежей работает именно так, ЮКасса подключается как дополнительный, альтернативный способ.
Я не спрашивал нужна или нет. Вы не найдете такого вопроса здесь.
Итак - я НЕ смогу ответить вам более подробно, чем описано в статье "Стажёр Вася и его истории об идемпотентности API", ссылку на которую я давал вам выше.
В чем КОНКРЕТНО в вашей ситуации 2 вариант будет иметь преимущество? Две строки, один вопрос. Сможете осилить?
Вы вообще со мной разговариваете? Ответы сервиса видите? - Нет!!! Сервис НЕ будет генерить ключ. Вообще. Никак. Точка! Он будет возвращать "invalid_request". Очнитесь.
На этом все. Дальше можно только ходить по кругу.
спасибо, но это именно то, что я вам скидывал и хотел, чтобы вы прочитали. Вы молодец, справились.Буду спать спокойно.
Т.е. через оф. клиента платеж будет создан в любом случае, это видно в исходниках и я провел тесты.Да при каждой попытке оплаты они будут генерить ключ. Имподентности нет и хрен с ней. Можете считать что Idempotence-Key это у вас какой то Invoice Id. Никакая имподентность вам нахрен не нужна. Каждый раз тупо генерите ключ.
Туннель, лифт, подземный переход.. что угодно в связке со слабой мобильной связью.
Стоят верблюд-сын и верблюд-отец. Сын спрашивает:
— Папа, а зачем нам на спине нужен горб?
— В горбу, сынок мы накапливаем воду. Когда мы идём по пустыне, нас не мучает жажда.
— Папа, а зачем нам такие копыта?
— Это чтобы в пустыне ноги не проваливались в песок.
— А зачем нам такие большие и жёсткие губы?
— Это чтобы в пустыне можно было есть колючки.
— Тогда, папа, объясни мне, на кой чёрт нам весь этот тюнинг в Саратовском зоопарке?..
Вы, возможно, скажете, мол как же так
Расскажите потом, удалось убедить разрабов сервиса, что ключ не нужен, лишний и вот эту историю с собакой. Тут всем будет полезно.
Если вы повторяете запрос с теми же данными и тем же ключом, API обрабатывает его как повторный. Если данные в запросе те же, а ключ идемпотентности отличается, запрос выполняется как новый.
if ($idempotenceKey) {
$headers[self::IDEMPOTENCY_KEY_HEADER] = $idempotenceKey;
} else {
$headers[self::IDEMPOTENCY_KEY_HEADER] = UUID::v4();
}А зачем отправлять повторно с тем же ключом?
Возможно - мне лень читать всю доку.
Если у вас УЖЕ есть уникальное поле, которое можно использовать как параметр идемпотентности, тогда ваш изначальный вопрос как его хранить или как генерировать вообще о чем? Вы не знаете как хранить номер договора? Или что значит "что использовать для ключа идемпотентности" - у вас же номер договора?
Мдяяяя мама была права. Сколько лет то говорите?