PHPackages spryker/app-payment - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Payment Processing](/categories/payments) 4. / 5. spryker/app-payment ActiveLibrary[Payment Processing](/categories/payments) spryker/app-payment =================== AppPayment module 3.5.1(5mo ago)04.0k↑50%1proprietaryPHPPHP >=8.2 Since Aug 2Pushed 5mo ago19 watchersCompare [ Source](https://github.com/spryker/app-payment)[ Packagist](https://packagist.org/packages/spryker/app-payment)[ RSS](/packages/spryker-app-payment/feed)WikiDiscussions master Synced 1mo ago READMEChangelog (10)Dependencies (37)Versions (18)Used By (1) AppPayment Module ================= [](#apppayment-module) [![Latest Stable Version](https://camo.githubusercontent.com/e59c06a0a3b64f3ec46162d93c471042ae891844401ac03548bd2a6c0b57ae68/68747470733a2f2f706f7365722e707567782e6f72672f737072796b65722f6170702d7061796d656e742f762f737461626c652e737667)](https://packagist.org/packages/spryker/app-payment)[![Minimum PHP Version](https://camo.githubusercontent.com/ec21f169d70b69344c67d6f18fa1a24d20476d2f0cd680e8c4a1534c22f34e5f/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f7068702d253345253344253230382e322d3838393242462e737667)](https://php.net/) Provides SyncAPI and AsyncAPI schema files and the needed code to be used in a Payment Service Provider App. Installation ------------ [](#installation) ``` composer require spryker/app-payment ``` ### Tenant-related packages [](#tenant-related-packages) - `spryker/sales-payment` - For the Payment processing. - `spryker/sales-payment-merchant` - For the Onboarding, Payout, and Payout reversal processing. - `spryker/merchant-app` - For the communication related to Merchants between the Tenant and the App. - `spryker/merchant-app-merchant-portal-gui` - For the displaying of the onboarding process and the onboarding status. ### Testing the AppPayment [](#testing-the-apppayment) You can test the AppPayment as usual with Codeception. Before that you need to run some commands: ``` composer setup ``` With these commands you've set up the AppPayment and can start the tests ``` vendor/bin/codecept build vendor/bin/codecept run ``` Documentation ============= [](#documentation) High-Level Architecture ======================= [](#high-level-architecture) [![AppPayment High-Level Architecture](docs/images/app-payment-high-level-architecture.svg)](https://docs.spryker.com/) Features ======== [](#features) Initialize Payment ------------------ [](#initialize-payment) This is triggered from the Tenant side when a customer places an order. The request contains all the Tenant's’s known data that is relevant to initialize a payment. Capture Payment --------------- [](#capture-payment) This is initiated via the `CapturePayment` message sent from the Tenant. The corresponding `PaymentTransfer` as well as the `AppConfigTransfer` are loaded from the database and passed via the `CapturePaymentRequestTransfer` to the Platform implementation. Cancel Payment -------------- [](#cancel-payment) This is initiated via the `CancelPayment` message sent from the Tenant. The corresponding `PaymentTransfer` as well as the `AppConfigTransfer` are loaded from the database and passed via the `CancelPaymentRequestTransfer` to the Platform implementation. Refund Payment -------------- [](#refund-payment) This is initiated via the `RefundPayment` message sent from the Tenant. The corresponding `PaymentTransfer` as well as the `AppConfigTransfer` are loaded from the database and passed via the `RefundPaymentRequestTransfer` to the Platform implementation. Handle Webhooks --------------- [](#handle-webhooks) Webhooks are piped through this package and extended with the needed Payment or Refund information for this webhook and are forwarded to the Platform implementation. Transfer Money -------------- [](#transfer-money) This is known on the Tenant side as Payout or Reverse Payout. This feature will be used together with merchants (when `spryker/app-merchant`) is also used. - `/private/initialize-payment` - Used from the Tenant side to initialize a payment. - `/private/confirm-pre-order-payment` - Used from the Tenant side to confirm pre-order payment after the order was persisted. - `/private/cancel-pre-order-payment` - Used from the Tenant side to cancel pre-order payment after the order was persisted. - `/private/payments/transfers` - Used from the Tenant side to do money transfer from the Marketplace to Merchant accounts. - `/private/customer` - Used from the Tenant side to get customer details. Usually, used for express-checkout strategies. ### AppKernel [](#appkernel) - \\Spryker\\Zed\\AppPayment\\Communication\\Plugin\\AppKernel\\ConfigurePaymentMethodsConfigurationAfterSavePlugin - \\Spryker\\Zed\\AppPayment\\Communication\\Plugin\\AppKernel\\DeleteTenantPaymentsConfigurationAfterDeletePlugin - \\Spryker\\Zed\\AppPayment\\Communication\\Plugin\\AppKernel\\SendAddPaymentMethodMessageConfigurationAfterSavePlugin - \\Spryker\\Zed\\AppPayment\\Communication\\Plugin\\AppKernel\\SendDeletePaymentMethodMessagesConfigurationAfterDeletePlugin APIs ==== [](#apis) - `resources/api/asyncapi.yml` - `resources/api/openapi.yml` Configuration ------------- [](#configuration) ### App Identifier [](#app-identifier) config/Shared/config\_default.php ``` use Spryker\Shared\AppPayment\AppConstants; $config[AppConstants::APP_IDENTIFIER] = getenv('APP_IDENTIFIER') ?: 'hello-world'; ``` Extensions ---------- [](#extensions) - \\Spryker\\Zed\\AppPayment\\Dependency\\Plugin\\AppPaymentPlatformMarketplacePluginInterface - \\Spryker\\Zed\\AppPayment\\Dependency\\Plugin\\AppPaymentPlatformPaymentMethodsPluginInterface - \\Spryker\\Zed\\AppPayment\\Dependency\\Plugin\\AppPaymentPlatformPaymentPagePluginInterface - \\Spryker\\Zed\\AppPayment\\Dependency\\Plugin\\AppPaymentPlatformPluginInterface - \\Spryker\\Zed\\AppPayment\\Dependency\\Plugin\\AppPaymentPlatformPreOrderPluginInterface - \\Spryker\\Zed\\AppPayment\\Dependency\\Plugin\\PaymentTransmissionsRequestExtenderPluginInterface - \\Spryker\\Zed\\AppPayment\\Dependency\\Plugin\\AppPaymentPlatformCustomerPluginInterface ### AppPaymentPlatformMarketplacePluginInterface [](#apppaymentplatformmarketplaceplugininterface) You can implement this plugin when your PSP App supports Marketplace capabilities. ### AppPaymentPlatformPaymentMethodsPluginInterface [](#apppaymentplatformpaymentmethodsplugininterface) This plugin must be implemented to provide the payment methods that the PSP App supports. ### AppPaymentPlatformPaymentPagePluginInterface [](#apppaymentplatformpaymentpageplugininterface) This plugin can be implemented to provide a payment page that the PSP App supports. This is only needed when using the redirect flows after the order was created. ### AppPaymentPlatformPluginInterface [](#apppaymentplatformplugininterface) This is the root plugin which must be implemented to provide the PSP App capabilities from the project level. ### AppPaymentPlatformPreOrderPluginInterface [](#apppaymentplatformpreorderplugininterface) This plugin can be implemented to provide the pre-order capabilities that the PSP App supports. When using the pre-order payment flow, the InitializePayment API endpoint is used before the order gets persisted and it returns the needed data for an headless approach to add the payment page on project side. Usually, this is done via a provided JavaScript that is send to the frontend in the InitializePayment API call response. On project side the customer than makes the Payment via the provided JavaScripts and the payment page provided by the PSP provider. After the order is persistzed on the project side a call to the ConfirmPreOrderPayment API endpoint is made to confirm the payment and connect it with the orderReference. ### PaymentTransmissionsRequestExtenderPluginInterface [](#paymenttransmissionsrequestextenderplugininterface) This plugin can be implemented to extend the request data that is send to the PSP App when doing payouts to Merchants. This is usually only needed when the PSP App supports Marketplace capabilities. ### AppPaymentPlatformCustomerPluginInterface [](#apppaymentplatformcustomerplugininterface) This plugin can be implemented to provide the customer details that the PSP App supports. This is usually only needed when the PSP App supports express-checkout strategies where the customer does not enter the normal checkout flow provided by Spryker. In this case, the Payment Service Provider provides the customer details such as shipping or billing address. Configure the MessageBroker --------------------------- [](#configure-the-messagebroker) Add this to your app configuration: ``` $config[MessageBrokerConstants::MESSAGE_TO_CHANNEL_MAP] = $config[MessageBrokerAwsConstants::MESSAGE_TO_CHANNEL_MAP] = [ PaymentAuthorizedTransfer::class => 'payment-events', PaymentAuthorizationFailedTransfer::class => 'payment-events', PaymentCapturedTransfer::class => 'payment-events', PaymentCaptureFailedTransfer::class => 'payment-events', PaymentRefundedTransfer::class => 'payment-events', PaymentRefundFailedTransfer::class => 'payment-events', PaymentCanceledTransfer::class => 'payment-events', PaymentCancellationFailedTransfer::class => 'payment-events', CancelPaymentTransfer::class => 'payment-commands', CapturePaymentTransfer::class => 'payment-commands', RefundPaymentTransfer::class => 'payment-commands', AddPaymentMethodTransfer::class => 'payment-method-commands', UpdatePaymentMethodTransfer::class => 'payment-method-commands', DeletePaymentMethodTransfer::class => 'payment-method-commands', PaymentCreatedTransfer::class => 'payment-events', PaymentUpdatedTransfer::class => 'payment-events', // App event AppConfigUpdatedTransfer::class => 'app-events', ]; $config[MessageBrokerConstants::CHANNEL_TO_TRANSPORT_MAP] = [ 'app-events' => MessageBrokerAwsConfig::HTTP_TRANSPORT, 'payment-events' => MessageBrokerAwsConfig::HTTP_TRANSPORT, 'payment-method-commands' => MessageBrokerAwsConfig::HTTP_TRANSPORT, 'payment-commands' => MessageBrokerAwsConfig::SQS_TRANSPORT, ]; $config[MessageBrokerAwsConstants::CHANNEL_TO_SENDER_TRANSPORT_MAP] = [ 'app-events' => MessageBrokerAwsConfig::HTTP_TRANSPORT, 'payment-events' => MessageBrokerAwsConfig::HTTP_TRANSPORT, 'payment-method-commands' => MessageBrokerAwsConfig::HTTP_TRANSPORT, ]; $config[MessageBrokerAwsConstants::CHANNEL_TO_RECEIVER_TRANSPORT_MAP] = [ 'payment-commands' => MessageBrokerAwsConfig::SQS_TRANSPORT, ]; ``` Zed --- [](#zed) - `\Spryker\Zed\AppPayment\AppPaymentConfig::getPaymentProviderName()` - `\Spryker\Zed\AppPayment\AppPaymentConfig::getIsTenantPaymentsDeletionAfterDisconnectionEnabled()` - `\Spryker\Zed\AppPayment\AppPaymentConfig::getHandleableWebhookTypes()` ### GetPaymentProviderName [](#getpaymentprovidername) This must be overridden on the project level and must return the name of the Payment Provider e.g. Stripe, PayOne, etc ### GetIsTenantPaymentsDeletionAfterDisconnectionEnabled [](#getistenantpaymentsdeletionafterdisconnectionenabled) This can be configured in the `config_default.php` of the App via `AppPaymentConstants::IS_TENANT_PAYMENTS_DELETION_AFTER_DISCONNECTION_ENABLED`. By default, this is false. When you want to delete all payments from the Apps database set this to true and when the App gets disconnected, all Payments of this Tenant will be removed from the database. ### GetHandleableWebhookTypes [](#gethandleablewebhooktypes) The default values of these are - `payment` - `refund` You can add other types in case you need more. The types are defined in `\Spryker\Zed\AppPayment\Business\Payment\Webhook\WebhookDataType` and via the `\Spryker\Glue\AppWebhookBackendApi\Plugin\AppWebhookBackendApi\GlueRequestWebhookMapperPluginInterface` the implementation sets this type to the `WebhookRequestTransfer`. Database -------- [](#database) This package adds the following database tables to the App - `spy_payment` - Contains all payments of a Tenant. - `spy_payment_transfer` - Contains all money transfers. - `spy_payment_refund` - Contains all refunded payments. Plugins ======= [](#plugins) This package provides the following plugins Glue ---- [](#glue) - `\Spryker\Glue\AppPaymentBackendApi\Plugin\GlueApplication\AppPaymentBackendApiRouteProviderPlugin` ### AppPaymentBackendApiRouteProviderPlugin [](#apppaymentbackendapirouteproviderplugin) This plugin must be added to the `\Pyz\Glue\GlueBackendApiApplication\GlueBackendApiApplicationDependencyProvider::getRouteProviderPlugins()`. It adds the following URLs to the App: - `/payment/initialize` - `/payments/transfers` Zed --- [](#zed-1) - `\Spryker\Zed\AppPayment\Communication\Plugin\AppKernel\DeleteTenantPaymentsConfigurationAfterDeletePlugin` - `\Spryker\Zed\AppPayment\Communication\Plugin\AppKernel\SendAddPaymentMethodMessageConfigurationAfterSavePlugin` - `\Spryker\Zed\AppPayment\Communication\Plugin\AppKernel\SendDeletePaymentMethodMessageConfigurationAfterDeletePlugin` - `\Spryker\Zed\AppPayment\Communication\Plugin\AppWebhook\PaymentWebhookHandlerPlugin` - `\Spryker\Zed\AppPayment\Communication\Plugin\MessageBroker\CancelPaymentMessageHandlerPlugin` - `\Spryker\Zed\AppPayment\Communication\Plugin\MessageBroker\CapturePaymentMessageHandlerPlugin` - `\Spryker\Zed\AppPayment\Communication\Plugin\MessageBroker\RefundPaymentMessageHandlerPlugin` ### DeleteTenantPaymentsConfigurationAfterDeletePlugin [](#deletetenantpaymentsconfigurationafterdeleteplugin) This plugin can be added to the `\Pyz\Zed\AppKernel\AppKernelDependencyProvider::getConfigurationAfterDeletePlugins()` and will drop all payments of a Tenant when configured to do so and when the App gets disconnected. ### SendAddPaymentMethodMessageConfigurationAfterSavePlugin [](#sendaddpaymentmethodmessageconfigurationaftersaveplugin) This plugin can be added to the `\Pyz\Zed\AppKernel\AppKernelDependencyProvider::getConfigurationAfterSavePlugins()` and will send an `AddPaymentMethod` message when the App gets configured. The message is not sent when App is in “disconnected“ state. Details of the message can be seen in `resources/api/asyncapi.yml` ### SendDeletePaymentMethodMessageConfigurationAfterDeletePlugin [](#senddeletepaymentmethodmessageconfigurationafterdeleteplugin) This plugin can be added to the `\Pyz\Zed\AppKernel\AppKernelDependencyProvider::getConfigurationAfterDeletePlugins()` and sends a `DeletePaymentMethod` message when the app gets disconnected. Details of the message can be seen in `resources/api/asyncapi.yml` ### PaymentWebhookHandlerPlugin [](#paymentwebhookhandlerplugin) This plugin can be added to the `\Pyz\Zed\AppWebhook\AppWebhookDependencyProvider::getWebhookHandlerPlugins()` and handles all Payment-related webhook requests. It ensures that a transaction ID is passed and forwards the `WebhookRequestTransfer` to the platform implementation. The returned `WebhookResponseTransfer` can be either successful or failed. In a successful case, the response must contain either `WebhookResponseTransfer::PAYMENT_STATUS` or `WebhookResponseTransfer::REFUND_STATUS`. Possible states are defined in the `\Spryker\Zed\AppPayment\Business\Payment\Status\PaymentStatus`. Based on the returned status the AppPayment package sends a defined message to the Tenant. - `PaymentStatus::STATUS_CAPTURED` - Sends a PaymentCaptured message to the Tenant. - `PaymentStatus::STATUS_CAPTURE_FAILED` - Sends a PaymentCaptureFailed message to the Tenant. - `PaymentStatus::STATUS_AUTHORIZED` - Sends a PaymentAuthorized message to the Tenant. - `PaymentStatus::STATUS_AUTHORIZATION_FAILED` - Sends a PaymentAuthorizationFailed message to the Tenant. - `PaymentRefundStatus::PENDING` - Sends no message to the Tenant this is an initial state and does not need further action. - `PaymentRefundStatus::SUCCEEDED` - Sends a PaymentRefunded message to the Tenant. - `PaymentRefundStatus::FAILED` - Sends a PaymentRefundFailed message to the Tenant. ### CancelPaymentMessageHandlerPlugin [](#cancelpaymentmessagehandlerplugin) This plugin can be added to the `\Pyz\Zed\MessageBroker\MessageBrokerDependencyProvider::getMessageHandlerPlugins()` and when the Tenant sends this message the related payment will be loaded from the database and is forwarded to the platform implementation via the `CancelPaymentRequestTransfer`. The platform implementation will return a `CancelPaymentResponseTransfer` with a status. - `PaymentStatus::STATUS_CANCELED` - Sends PaymentCanceled message to the Tenant. - `PaymentStatus::STATUS_CANCELLATION_FAILED` - Sends a `PaymentCancelationFailed` message to the Tenant. ### CapturePaymentMessageHandlerPlugin [](#capturepaymentmessagehandlerplugin) This plugin can be added to the `\Pyz\Zed\MessageBroker\MessageBrokerDependencyProvider::getMessageHandlerPlugins()` and when the Tenant sends this message the related payment will be loaded from the database and is forwarded to the platform implementation via the `CapturePaymentRequestTransfer`. The platform implementation will return a `CapturePaymentResponseTransfer` with a status. - `PaymentStatus::STATUS_CAPTURED` - Sends a `PaymentCaptured` message to the Tenant. - `PaymentStatus::STATUS_CAPTURE_FAILED` - Sends a `PaymentCaptureFailed` message to the Tenant. ### RefundPaymentMessageHandlerPlugin [](#refundpaymentmessagehandlerplugin) This plugin can be added to the `\Pyz\Zed\MessageBroker\MessageBrokerDependencyProvider::getMessageHandlerPlugins()` and when the Tenant sends this message the related payment will be loaded from the database and is forwarded to the platform implementation via the `RefundPaymentRequestTransfer`. The platform implementation will return a `RefundPaymentResponseTransfer` with a status. - `PaymentRefundStatus::PENDING` - Sends no message to the Tenant this is an initial state and does not need further action. - `PaymentRefundStatus::SUCCEEDED` - Sends a PaymentRefunded message to the Tenant. - `PaymentRefundStatus::FAILED` - Sends a PaymentRefundFailed message to the Tenant. Extension ========= [](#extension) This package provides the following extension points Zed --- [](#zed-2) - `\Spryker\Zed\AppPayment\Dependency\Plugin\PaymentTransmissionsRequestExtenderPluginInterface` - `\Spryker\Zed\AppPayment\Dependency\Plugin\AppPaymentPlatformPaymentPagePluginInterface` - `\Spryker\Zed\AppPayment\Dependency\Plugin\AppPaymentPlatformPluginInterface` - `\Spryker\Zed\AppPayment\Dependency\Plugin\AppPaymentPlatformMarketplacePluginInterface` ### PaymentTransmissionsRequestExtenderPluginInterface [](#paymenttransmissionsrequestextenderplugininterface-1) This plugin can be implemented by other packages e.g. to group PaymentTransmissions (Transfer of Money from one account to another account, used e.g. for grouping transfer of money by merchants). The `PaymentTransmissionsRequestTransfer` contains all order-relevant data to be processed. ### AppPaymentPlatformPaymentPagePluginInterface [](#apppaymentplatformpaymentpageplugininterface-1) This plugin is used when a PSP offers a Payment Page which the user gets redirected to after an order is placed. The `PaymentPageRequestTransfer` contains the transaction ID, the `AppConfigTransfer`, and the `PaymentTransfer`. The returned `PaymentPageResponseTransfer` has to contain a `paymentPageTemplate` name and the `paymentPageData` that has to be rendered on this page. ### AppPaymentPlatformPluginInterface [](#apppaymentplatformplugininterface-1) This plugin must be implemented in the PSP App to provide the needed functionality to make payments. The following methods are provided: - `initializePayment` - `capturePayment` - `cancelPayment` - `refundPayment` - `handleWebhook` - `getPaymentStatus` #### InitializePayment [](#initializepayment) This is triggered from the Tenant side when a customer places an order. The request contains all the Tenant's’s known data that is relevant to initialize a payment. The platform implementation must return a `InitializePaymentResponseTransfer`. It must provide if the initialization was successful or not, it must return a transaction ID and can return (depending on the storefront implementation) redirectUrl. In failure cases, it can also return a message. The information is sent back to the Tenant who can act accordingly. #### CapturePayment [](#capturepayment) This is initiated via the `CapturePayment` message sent from the Tenant. The corresponding `PaymentTransfer` as well as the `AppConfigTransfer` are loaded from the database and passed via the `CapturePaymentRequestTransfer` to the Platform implementation. The platform implementation must return a `CapturePaymentResponseTransfer`. It must provide if the capturing was successful or not and the payment status. In failure cases, it must return a message. #### CancelPayment [](#cancelpayment) This is initiated via the `CancelPayment` message sent from the Tenant. The corresponding `PaymentTransfer` as well as the `AppConfigTransfer` are loaded from the database and passed via the `CancelPaymentRequestTransfer` to the Platform implementation. The platform implementation must return a `CancelPaymentResponseTransfer`. It must provide if the canceling was successful or not and the payment status. In failure cases, it must return a message. #### RefundPayment [](#refundpayment) This is initiated via the `RefundPayment` message sent from the Tenant. The corresponding `PaymentTransfer` as well as the `AppConfigTransfer` are loaded from the database and passed via the `RefundPaymentRequestTransfer` to the Platform implementation. The platform implementation must return a `RefundPaymentResponseTransfer`. It must provide if the refund was successful or not and the payment status. In failure cases, it must return a message. #### HandleWebhook [](#handlewebhook) Webhooks are piped through this package and extended with the needed Payment or Refund information for this webhook and are forwarded to the Platform implementation. ### AppPaymentPlatformMarketplacePluginInterface [](#apppaymentplatformmarketplaceplugininterface-1) This plugin must be implemented in the PSP App to provide the needed functionality to do payout and reverse payouts for Marketplaces. The following methods are provided: - `transferPayments` #### TransferMoney [](#transfermoney) This is known on the Tenant side as Payout or Reverse Payout. This feature will be used together with merchants (when spryker/app-merchant) is also used. The process is initiated from the Tenant side and in the request all orderItems and the corresponding order will be passed to the App. The orderItems will be grouped into `PaymentTransmissionTransfers` and are forwarded to the Platform implementation. The platform implementation must set the successful state of each transfer and in a failure case, it must add a failure message. The payment transfers are persisted on the App side and a response with all the transmissions successful or failed will be returned in the response to the Tenant. ### Configure Payment Methods [](#configure-payment-methods) Each PSP implementation has different Payment Methods available. Through the `\Spryker\Zed\AppPayment\Dependency\Plugin\AppPaymentPlatformPaymentMethodsPluginInterface` you can provide the available Payment Methods. Each Payment Method can also have different configuration details. Add the plugin interface to your implementation and you can configure the payment methods. #### Payment Method default configuration [](#payment-method-default-configuration) This package adds endpoints to be used from the SCOS side to each of the configured Payment Methods. The default configuration for each Payment Method is: - The base URL - This is the URL that the SCOS side will use to call the PSP App. - Endpoints - The endpoints that the SCOS side will call on the PSP App. - `authorization` - The endpoint to initialize a Payment, `/private/initialize-payment` - `pre-order-confirmation` - The endpint to confirm a PreOrder payment, `/private/confirm-pre-order-payment` - `pre-order-cancellation` - The endpint to cancel a PreOrder payment, `/private/cancel-pre-order-payment` - `transfer` - The endpoint to transfer money to a Merchant, `/private/transfers` These are used on the SCOS side by their names. F.e. when the SCOS side wants to initialize a payment it will call the `authorization` endpoint on the PSP App. #### Payment Service Provider with only one Payment Method [](#payment-service-provider-with-only-one-payment-method) A simple example for a PSP with only one Payment Method could look like this: ``` public function configurePaymentMethods(PaymentMethodConfigurationRequestTransfer $paymentMethodConfigurationRequestTransfer): PaymentMethodConfigurationResponseTransfer { $paymentMethodConfigurationResponseTransfer = new PaymentMethodConfigurationResponseTransfer(); $checkoutConfigurationTransfer = new CheckoutConfigurationTransfer(); $checkoutConfigurationTransfer->setStrategy('embedded'); $checkoutConfigurationTransfer->setScripts([ ... ]); $paymentMethodAppConfigurationTransfer = new PaymentMethodAppConfigurationTransfer(); $paymentMethodAppConfigurationTransfer ->setCheckoutConfiguration($checkoutConfigurationTransfer); $paymentMethodTransfer = new PaymentMethodTransfer(); $paymentMethodTransfer ->setName('Foo') ->setProviderName('Bar') ->setPaymentMethodAppConfiguration($paymentMethodAppConfigurationTransfer); $paymentMethodConfigurationResponseTransfer->addPaymentMethod($paymentMethodTransfer); return $paymentMethodConfigurationResponseTransfer; } ``` Here we configure exactly one payment method. The payment method is named "Foo" and the provider is named "Bar". The Payment method also has a configuration that will be persisted on the SCOS side. The strategy is set to "embedded" which means that the payment page will be embedded in the SCOS checkout. The scripts are the scripts that are needed to embed and run the payment page in the SCOS checkout. This code runs when the PSP App gets configured. After this method call the so configured methods will be persisted on the App sides database, enriched with default configurations, and via the AddPaymentMethod message sent to the SCOS side. When the App gets reconfigured and a different number of Payment Methods are configured, the DeletePaymentMethod message will be sent to the SCOS side and the previously configured Payment Methods for the current Tenant will be deleted from the database. When the PaymentMethod configuration has changed the UpdatePaymentMethod message will be sent to the SCOS side. #### Payment Service Provider with multiple Payment Methods [](#payment-service-provider-with-multiple-payment-methods) In case you have multiple payment methods, you can add multiple PaymentMethodTransfer objects to the PaymentMethodConfigurationResponseTransfer object. For this, you can get the AppConfigTransfer from the PaymentMethodConfigurationRequestTransfer. An example could look like this: ``` public function configurePaymentMethods(PaymentMethodConfigurationRequestTransfer $paymentMethodConfigurationRequestTransfer): PaymentMethodConfigurationResponseTransfer { $appConfigTransfer = $paymentMethodConfigurationRequestTransfer->getAppConfig(); // Contains ['bar'] which was the only one selected through the configuration page $configuredPaymentMethods = $appConfigTransfer->getPaymentMethods(); // These are all methods you can provide which are configurable through the AppStore Catalogs App configuration page $availablePaymentMethods = [ 'foo', 'bar', 'baz', ]; $paymentMethodConfigurationResponseTransfer = new PaymentMethodConfigurationResponseTransfer(); foreeach ($availablePaymentMethods as $paymentMethodName) { if (!isset($configuredPaymentMethods[$paymentMethodName])) { continue; } $paymentMethodTransfer = new PaymentMethodTransfer(); $paymentMethodTransfer ->setName($paymentMethodName) ->setProviderName('PaymentProviderName'); $paymentMethodConfigurationResponseTransfer->addPaymentMethod($paymentMethodTransfer); } return $paymentMethodConfigurationResponseTransfer; } ``` In this example you would get one PaymentMethod added to SCOS via the AddPaymentMethod message. The PaymentMethod is named "bar" and the provider is named "PaymentProviderName". #### Payment Method Checkout Configuration [](#payment-method-checkout-configuration) Each Payment method can have a different checkout configuration. The checkout configuration is used to configure the payment that is used in the SCOS checkout. ##### Available checkout strategies [](#available-checkout-strategies) - `default` - By default Payment methods use the "default" strategy which means that the payment page is opened in a new window. - `embedded` - The payment page is embedded in the SCOS checkout. This is useful when the payment page is provided by the PSP App and the SCOS side wants to embed it in the checkout. - `express-checkout` - This option is for example provided by PayPal Express. When the payment method has this strategy the SCOS side renders a button that opens the payment page in a modal. ###### Default strategy [](#default-strategy) The default strategy is used when no strategy is set. The default strategy is to open the payment page in a new window and will only be opened after the customer has submitted his order. In this strategy, the customer is redirected to the payment page which is called Hosted Payment Page. There the customer provides what the Payment Service Provider requests and after the payment is done on the hosted payment page the customer is redirected back to the SCOS side and see either the success or failure page. ###### Embedded strategy [](#embedded-strategy) The embedded strategy is used when the payment page is provided by the PSP App and the SCOS side wants to embed it in the checkout. This is useful when the PSP App provides a payment page that is designed to be embedded in the SCOS checkout. The payment page will then be included e.g. in the summary page of the checkout. ###### Express Checkout strategy [](#express-checkout-strategy) The express checkout strategy is used when the payment method provides an express checkout. This is useful when the payment method provides a button that opens the payment page in a modal. This is useful when the payment page is provided by the PSP App and the SCOS side wants to open it in a modal. The button can be included in different places such as the Cart Page o a Product Detail Page. ### Health Score 45 — FairBetter than 93% of packages Maintenance72 Regular maintenance activity Popularity20 Limited adoption so far Community20 Small or concentrated contributor base Maturity61 Established project with proven stability Bus Factor2 2 contributors hold 50%+ of commits How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~31 days Recently: every ~83 days Total 17 Last Release 157d ago Major Versions 1.1.1 → 2.0.02024-09-05 2.2.1 → 3.0.02024-11-27 2.2.2 → 3.1.02024-12-12 PHP version history (2 changes)1.0.0PHP >=8.1 2.1.0PHP >=8.2 ### Community Maintainers ![](https://avatars.githubusercontent.com/u/10738957?v=4)[Spryker Bot](/maintainers/spryker-bot)[@spryker-bot](https://github.com/spryker-bot) --- Top Contributors [![stereomon](https://avatars.githubusercontent.com/u/1382877?v=4)](https://github.com/stereomon "stereomon (20 commits)")[![vol4onok](https://avatars.githubusercontent.com/u/5063777?v=4)](https://github.com/vol4onok "vol4onok (14 commits)")[![matweew](https://avatars.githubusercontent.com/u/454530?v=4)](https://github.com/matweew "matweew (6 commits)")[![vitaliiShveider](https://avatars.githubusercontent.com/u/95642976?v=4)](https://github.com/vitaliiShveider "vitaliiShveider (1 commits)")[![spryker-release-bot](https://avatars.githubusercontent.com/u/26904324?v=4)](https://github.com/spryker-release-bot "spryker-release-bot (1 commits)")[![pushokwhite](https://avatars.githubusercontent.com/u/4017411?v=4)](https://github.com/pushokwhite "pushokwhite (1 commits)")[![abitskil](https://avatars.githubusercontent.com/u/10989183?v=4)](https://github.com/abitskil "abitskil (1 commits)") ### Code Quality TestsCodeception Static AnalysisPHPStan, Rector Type Coverage Yes ### Embed Badge ![Health badge](/badges/spryker-app-payment/health.svg) ``` [![Health](https://phpackages.com/badges/spryker-app-payment/health.svg)](https://phpackages.com/packages/spryker-app-payment) ``` ### Alternatives [spryker/search Search module 152.8M64](/packages/spryker-search) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)