SisoPaymentBundle defines and implements an interface to the
The main interface is represented by
PaymentServiceInterface, which is the public access point to payment processing.
PaymentServiceInterface::processPayment() starts all payment processes.
It tries to process the payment and throws a
if the payment method represented by
paymentMethodIdentifier needs an HTTP redirection to a payment portal site to advance the payment
(for example for an input of critical data like a credit card number).
The calling instance must take responsibility for this exception and handle the redirection accordingly.
The following data is necessary to start the payment process:
orderIdis a valid identifier for the instance that holds the order data
paymentMethodIdentifieris a string that uniquely identifies a payment plugin implementation
amountholds the amount to be paid (in the lowest available unit of currency, e.g. euro cents)
currencyholds a string that identifies the currency of the
extendedData(optional) can be used for specific configuration of the given
paymentMethodIdentifierand thus the respective payment plugin
If more user interaction is needed (e.g. to authorize the transaction at a payment gateway),
finalizePayment() method ends the payment process.
This method can also throw the
orderId parameter must pass the identifier of the order instance that was also passed to
additionalData parameter can be used to pass further information to the payment external data.
For example, it can extract important fields from the payment gateway's response.
After the payment process is successfully processed, you can get the respective transaction ID
that was provided by the payment gateway. For this, the interface provides the
A payment plugin (and most payment gateways) requires storing the return URLs in the extended data of the
This is because the related basket/order ID needs to be appended to the URL to determine the basket
and the related payment instruction for further processing in the returning URL requests.
It is impossible to configure the URLs via the service container, as the basket ID is determined dynamically.
You must implement this interface for every payment plugin, if more than the standard fields like amount are necessary for the payment process.
The interface defines a single method,
which builds and returns the respective configuration data in an associative array.
To register an implementation of this interface to
StandardPaymentService you need to define it as a service and tag it.
The tag name is
payment.plugin.config and it needs an attribute named
which must be the same as the plugin form
alias, for example:
1 2 3 4
StandardPaymentService implements the
PaymentInstructionBasketMap entity stores the relation between the shop's basket entities and the payment entities.
The service also uses
PluginConfigurationInterface to inject the respective payment configuration into