ExpressServiceProviderInterface
in
A module that sells services payable by one express SMS.
The System payment layer knows nothing about modules: it parses the SMS, asks the provider of
the module word to resolve "service for object ID", creates the payment and lets the module
create its own payment items. Activation then runs through the ordinary payment callback
(PaymentCallbackRegistry) exactly like a payment from the payment form.
Implementations live in the module's Api layer and are found by type in the DI container (ExpressServiceRegistry) — a new module only adds a class.
Table of Contents
Methods
- createPaymentItems() : bool
- Create the module payment items (inactive) for a payment the System layer just created.
- describe() : array<int, ExpressServiceDescription>
- Every express service the module offers right now through the gateway, for the administration overview and the Front offers.
- getModuleCode() : string
- Module word of the SMS text, one of {@see ExpressModuleCode}.
- hasPaymentItems() : bool
- Does the payment already have the module payment items? Read straight from the DB. The resumed processing of a redelivered SMS (the first run crashed after the payment was saved) asks before {@see createPaymentItems()} — a second set of items would activate twice.
- resolve() : ExpressResolution
- Validate the untrusted SMS data: the service must be one the module offers right now (an active quick price, or a tariff price for the gateway), the object must exist and be active.
Methods
createPaymentItems()
Create the module payment items (inactive) for a payment the System layer just created.
public
createPaymentItems(ExpressTarget $target, int $paymentId) : bool
The payment callback activates them once the payment is completed.
Parameters
- $target : ExpressTarget
- $paymentId : int
Return values
booldescribe()
Every express service the module offers right now through the gateway, for the administration overview and the Front offers.
public
describe(int $paymentGateId) : array<int, ExpressServiceDescription>
Parameters
- $paymentGateId : int
Return values
array<int, ExpressServiceDescription>getModuleCode()
Module word of the SMS text, one of {@see ExpressModuleCode}.
public
getModuleCode() : string
Return values
stringhasPaymentItems()
Does the payment already have the module payment items? Read straight from the DB. The resumed processing of a redelivered SMS (the first run crashed after the payment was saved) asks before {@see createPaymentItems()} — a second set of items would activate twice.
public
hasPaymentItems(int $paymentId) : bool
Parameters
- $paymentId : int
Return values
boolresolve()
Validate the untrusted SMS data: the service must be one the module offers right now (an active quick price, or a tariff price for the gateway), the object must exist and be active.
public
resolve(string $serviceCode, int $objectId, int $paymentGateId) : ExpressResolution
Returns one target per payment region / tariff offering it — the System layer then picks the one whose price and currency equal the number the SMS was sent to.
$paymentGateId = the SMS gateway that received the message; modules whose prices differ per
gateway (user tariffs) read their price for it, quick price modules ignore it.
Parameters
- $serviceCode : string
- $objectId : int
- $paymentGateId : int