Adamos

Вариант 4. Торжественно похоронить свой велосипед и использовать SafeMySQL, который легко превращается в синглтон и не требует никакого наследования для использования каким угодно образом.

Или по ссылке сможет зайти кто угодно, или никто.
Если обработчик доступен по ajax, в нем должна быть проверка авторизации. Других вариантов нет.

Дело в том, что поисковики индексируют не запросы, а страницы. Если у вас ajax-запрос получает данные для товара в формате json, а потом строит из них представление прямо на той же странице, не меняя ее адреса - как вы себе представляете эту страницу в выдаче поисковика?
Как бы поисковик ни понимал скрипты, логика "по этому адресу я видел этот текст", которой руководствуются поисковики, в таких случаях не работает.

Нужно, чтобы у каждого товара была своя четкая ссылка. Возможно, наполовину состоящая из GET-параметров, но уникальная. Для уверенного индексирования можно подсунуть роботу такие ссылки внутри тега noscript.
Ну, и sitemap построить и скормить Яндексу с Гуглем - они это любят.

К путям checkURL и paymentAvisoURL обращается сервер Кассы, а не браузер пользователя. Какая, к черту, авторизация?
И этому серверу действительно нужно обратиться из интернета к скрипту на вашем сервере. Как он это сделает, если сервер доступен только локально?
Вы, похоже, читали документацию не с начала и просто не поняли саму схему работы платежной системы.

FTP - это очевидное древнее зло, его можно использовать только в том случае, если вообще нет альтернатив или они еще страшнее (заливка через веб-морду, например).
Редактирование и сразу сохранение на боевой сервер - одна эта идея должна вызывать у разработчика приток адреналина от представления, чем это чревато.
Сохранение в теории может привести к тому, что на сервере окажется пустой или оборванный с середины файл. При использовании FTP и не слишком стабильного канала эта теория легко становится практикой.
Свежеисправленный файл с довольно большой вероятностью содержит ошибки. Даже не говоря о профессиональном тестировании - самому-то хотя бы убедиться, что результат работает примерно так, как ожидалось, надо убедиться, прежде чем выпускать это дело в свет. А еще лучше - постепенно делая одно изменение за другим, проверять, что реализация задуманного соответствует задумке. Обязательно нужен тестовый сервер.
Тем более, что, если код и файлы организованы грамотно, изменения на одной странице вполне могут означать одновременное изменение четырех файлов (стили, скрипты, класс с логикой, шаблон с представлением). Что будет, если пользователь зайдет на сайт, когда половина из этих файлов не будет обновлена? Хотите поотлавливать ошибки, в которые это выльется? Предположите, например, что эта страничка - корзина интернет-магазина и вы меняли что-то, касающееся товаров...

По-моему, правильное начало работы с фреймворками выглядит примерно так:
- начинаешь работать с CMS, плюешься от того, как все через задницу
- везде, где возможно, пишешь простые решения сам, игнорируя функционал CMS, потому что там кромешный оверхед
- переходя к более комплексным задачам, начинаешь городить свои велосипеды для того, что требуется постоянно, начиная понимать, что типовые задачи примерно ложатся в одни и те же ходы и решения, а решение этих задач с прицелом на расширяемость, универсальность и безопасность требует достаточно сложных, но одних и тех же схем
- начинаешь читать документацию по фреймворкам, где эти самые схемы воплощены без тех ошибок, которых ты нагородишь, пытаясь создать что-то свое
- пользуешься тем фреймворком, который показался наиболее логичным и подходящим под задачи.