Уведомление по платежу от яндекса может прийти в любое время, обычно раньше, чем клиент возвращается. И важно помнить, что идентификаторы платежа яндекса и магазина сопоставляются в первом же ответе от яндекса. Раньше было так, что в первый запрос к яндексу пишется свой идентификатор платежа, и в ответ яндекс отправляет данные заявки к платежу с указанием того самого идентификатора. Уже потом изменения статуса заявки могут приходить только с яндексовым идентификатором, там же идет связка invoiceId и paymentId, когда оплата проходит.
Так что проблем с отслеживанием быть не должно. Ибо invoiceId уже сформирован к моменту перенаправления клиента на яндекс. А paymentId становится известен чуть ли не сразу после оплаты на яндексе, когда клиенту выводится чек, в магазин идёт извещение по статусу оплаты.
На возвратную страницу лучше не совать идентификатор от яндекса, пусть будет свой, можно даже в сессию записать.
Оплата начинается с запроса от магазина, от яндекса приходит ответ, там будет invoiceId. Когда клиент на яндексе отдаст деньги, яндекс сделает запрос к магазину с указанием paymentId. Далее магазин самостоятельно должен опрашивать яндекс о статусе платежа.
return_url это ссылка для клиента, где магазин что-нибудь расскажет об оплате. Вообще, яндексу побоку, что на той return_url странице будет.
Механизм межпроцессного обмена данными, наряду с буферами и шинами.
Замена кода может понадобиться для горячего обновления, без остановки программ. Но это какой-то трудный путь.
Еще подумалось про кривую компиляцию, некоторая "онлайн" оптимизация программ.
Но это всё чушь какая-то.
https://jsfiddle.net/xpvt214o/98893/
вот так работает, сам исходный .block куда-то нужно убрать, функция должна быть нестрелочной, ибо объект this остаётся внешним, а не из множества .box.
Для авантюрных веб-разработчиков тяжеловато понять нужность сервиса по печатным платам, так и увлечь их тяжело. Иные же будут делиться лишь теоретическими умениями.
.need:active{/*свойства*/}
.need.click:active{/*перекрыть свойства*/}