Интеграция с платежными системами

Введение

L-Shop позволяет быстро добавлять интеграцию с платежными системами, отличными от стандартных.

Ход

Для того, чтобы добавить интеграцию с платежной системой вам нужно:

  • Создать класс и имплементировать интерфейс App\Services\Purchasing\Payers\Payer.

  • Написать реализацию для 5 методов: paymentUrl(), validate(), successAnswer(), name(), enabled().

/app/Services/Purchasing/Payers/CustomPayer.php
<?php
declare(strict_types = 1);

namespace App\Services\Purchasing\Payers;

use App\Entity\Purchase;

class CustomPayer implements Payer
{
    /**
     * Данный метод возвращает url, по которому пользователь должен перейти для
     * проведения оплаты.
     */
    public function paymentUrl(Purchase $purchase): string
    {
        //
    }

    /**
     * Валидирует массив входящих данных и отдает true - в случае если данные верны
     * и false - иначе. Этот метод вызывается, когда платежная система делает
     * запрос, дабы уведомить L-Shop о статусе оплаты.
     */
    public function validate(array $data): bool
    {
        //
    }

    /**
     * Возвращает строку успешного ответа. Этот ответ ожидает увидить платежная система
     * на запрос об уведомлении магазина об успешной оплате.
     */
    public function successAnswer(Purchase $purchase): string
    {
        //
    }

    /**
     * Возвращает внутреннее имя платежного сервиса. Используется только L-Shop'ом.
     */
    public function name(): string
    {
        //
    }

    /**
     * Возвращает true - если платежная система включена и false - если выключена.
     */
    public function enabled(): bool
    {
        //
    }
}
  • Зарегистрировать реализацию этой платежной системы.

    • Перейдите в файл /config/purchasing.php .

    • Добавьте полное имя класса нового payer'а в элемент массива payers.

/config/purchasing.php
'payers' => [
    // Builtin payers...
    \App\Services\Purchasing\Payers\RobokassaPayer::class,
    \App\Services\Purchasing\Payers\InterkassaPayer::class,
    
    // Custom payers...
    \App\Services\Purchasing\Payers\CustomPayer::class
],
  • Сбросьте кэш приложения, дабы новая конфигурация закэшировалась.

Спецификация

Ключевые слова "ДОЛЖЕН”, “НЕ ДОЛЖЕН”, “ ТРЕБУЕТСЯ”, “СЛЕДУЕТ”, “НЕ СЛЕДУЕТ”, “РЕКОМЕНДУЕТСЯ”, “МОЖЕТ” должны интерпретироваться так же, как описано в RFC 2119.

  • Класс payer ДОЛЖЕН реализовывать интерфейсApp\Services\Purchasing\Payers\Payer.

  • РЕКОМЕНДУЕТСЯ добавлять к имени класса суффикс Payer, дабы класс можно было идентифицировать по названию.

  • РЕКОМЕНДУЕТСЯ помещать payer'ы в неймспейс App\Services\Purchasing\Payer.

  • Реализация метода paymentUrl() ДОЛЖНА возвращать строку, являющуюся URL'ом по которому необходимо будет перейти пользователю для совершения оплаты.

  • Реализация метода validate() ДОЛЖНА возвращать результат валидации принятых данных, которые сформировала платежный сервис для сообщения о статусе платежа. Булево значение true означает, что принятые данные валидны, false - невалидны.

  • Реализация метода validate() МОЖЕТ бросать исключение типа App\Exceptions\Payer\InvalidPaymentDataException в случае невалидности полученных данных.

  • Реализация метода successAnswer() ДОЛЖНА возвращать строку, которая будет возвращена платежному сервису в случае валидности данных, переданных в метод validate() в ответ на запрос о сообщении статуса платежа.

  • Реализация метода name() ДОЛЖНА возвращать строку, являющуюся именем платежной системы. Это значение будет видеть пользователь при взаимодействии с системой.

  • Реализация метода enabled() ДОЛЖНА возвращать булево значение, которое говорит о том, доступна ли данная реализация payer'а для работы или нет.

Last updated