Вот это тоже не верно. Вы НЕ понимаете как работает сервис, вот и всё.
Здесь можно ставить точку.
При ста попытках без "Idempotence-Key" будет создано 100 платежей, которые будут висеть в ЛК ЮКасса в статусе "Не оплачен". И только если 101 будет успешным, в аналитике будет 101 платеж.
Вопрос здесь был задан, т.к. до этого момента, номера договоров не хранились в БД сайта, за ненадобностью. Прежде чем писать код, я попросил сообщество поделиться опытом.
Александр Талалаев, чей ответ я отметил решением, дал конкретный ответ. Сразу. Понимаете?
Вы же втянули меня в такой блудняк.. но это было здорово). Уже в 10й раз говорю вам спасибо.В блудняк втянули себя вы. Если бы вы остановились бы и задумались банально на ПЕРВОМ вопросе, - то было бы 2 варианта продолжения. Вы бы поняли что имодентность и возня с сохранением вам не нужна, можно было бы без нее, либо вы описали такой контекст задачи что я бы понял что вам она нужна, и сразу бы предложил вариант генерации UUID на основе данных.
ключ идемпонентности (Idempotence-Key) и id платежа (payment_id) - это разные вещи. Вы чего?
Упростим просто для примера Idempotence-Key до номера договора.
Зачем, по вашему, создавать новый объект платежа, если данные неизменны?
Зачем 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();
}А зачем отправлять повторно с тем же ключом?
вы видимо не прочитали последние 2 сообщения где я цитирую автора. ну или надо еще раз. Мне добавить нечего к прямым цитатам и моим комментариям, могу только посоветовать читать до просветления.
Лучшее в чем? В функционале или в количестве памяти на реализацию функционала? И еще раз если брать какой нибудь статический массив на сях - никаких накладных расходов по памяти. Но вагон минусов по функционалу. Массив в php - хеш таблица, с вагоном плюсов по функционалу, но вагон оверхеда по памяти. Создаете массив в php - надо понимать что в памяти будет валяться не только переменная а вагон всего. Ну это и есть тяжесть. В чем так сказать ваши претензии? Я написал что-то неверное? Да вродь нет. Вам нравится реализация массивов в PHP? Мне тоже - но это не отменяет того что там вагон оверхеда по памяти и надо понимать что $arr = [1]; у вас памяти займется несколько больше нежели 1. Вы просто испытываете боль от упоминания оверхеда? ну примите нурофен