Payment

Starting with version 6.4.1.0, Shopware also provides functionality for your app to be able to integrate payment providers. You can choose between just a simple request for approval in the background (synchronous payment) and the user being forwarded to a provider for payment (asynchronous payment). You provide one or two endpoints, one for starting the payment and providing a redirect URL and one for finalization to check for the resulting status of the payment. The requests and responses of all of your endpoints will be signed and feature JSON content.
Prerequisites
You should be familiar with the concept of Apps and their registration.
App Base Guide
To reproduce this example, you should also be aware of how to set up an app on your development platform.
Local development
Manifest configuration
If your app should provide one or multiple payment methods, you need to define these in your manifest. The created payment methods in Shopware will be identified by the name of your app and the identifier you define per payment method. You should therefore not change the identifier after release, otherwise new payment methods will be created.
You may choose between a synchronous and an asynchronous payment method. These two types are differentiated by defining a finalize-url or not. If no finalize-url is defined, the internal Shopware payment handler will default to a synchronous payment. If you do not want or need any communication during the payment process with your app, you can also choose not to provide a pay-url, then the payment will remain on open on checkout.
Below you can see three different definitions of payment methods.
manifest.xml
1
<?xml version="1.0" encoding="UTF-8"?>
2
<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/shopware/platform/trunk/src/Core/Framework/App/Manifest/Schema/manifest-1.0.xsd">
3
    <meta>
4
        <!-- The name of the app should not change. Otherwise all payment methods are created as duplicates. -->
5
        <name>PaymentApp</name>
6
        <!-- ... -->
7
    </meta>
8
​
9
    <payments>
10
        <payment-method>
11
            <!-- The identifier of the payment method should not change. Otherwise a separate method is created. -->
12
            <identifier>asynchronousPayment</identifier>
13
            <name>Asynchronous payment</name>
14
            <name lang="de-DE">Asynchrone Zahlung</name>
15
            <description>This payment method requires forwarding to payment provider.</description>
16
            <description lang="de-DE">Diese Zahlungsmethode erfordert eine Weiterleitung zu einem Zahlungsanbieter.</description>
17
            <pay-url>https://payment.app/async/pay</pay-url>
18
            <finalize-url>https://payment.app/async/finalize</finalize-url>
19
            <!-- This optional path to this icon must be relative to the manifest.xml -->
20
            <icon>Resources/paymentLogo.png</icon>
21
        </payment-method>
22
​
23
        <payment-method>
24
            <!-- The identifier of the payment method should not change. Otherwise a separate method is created. -->
25
            <identifier>synchronousPayment</identifier>
26
            <name>Synchronous payment</name>
27
            <name lang="de-DE">Synchrone Zahlung</name>
28
            <description>This payment method does everything in one request.</description>
29
            <description lang="de-DE">Diese Zahlungsmethode arbeitet in einem Request.</description>
30
            <!-- This URL is optional for synchronous payments (see below). -->
31
            <pay-url>https://payment.app/sync/process</pay-url>
32
        </payment-method>
33
​
34
        <payment-method>
35
            <!-- The identifier of the payment method should not change. Otherwise a separate method is created. -->
36
            <identifier>simpleSynchronousPayment</identifier>
37
            <name>Simple Synchronous payment</name>
38
            <name lang="de-DE">Einfache synchrone Zahlung</name>
39
            <description>This payment will not do anything and stay on 'open' after order.</description>
40
            <description lang="de-DE">Diese Zahlungsmethode wird die Transaktion auf 'offen' belassen.</description>
41
            <!-- No URL is provided. -->
42
        </payment-method>
43
​
44
        <payment-method>
45
            <!-- The identifier of the payment method should not change. Otherwise a separate method is created. -->
46
            <identifier>allBellsAndWhistlesPayment</identifier>
47
            <name>Payment, that offers everything</name>
48
            <name lang="de-DE">Eine Zahlungsart, die alles kann</name>
49
            <pay-url>https://payment.app/async/pay</pay-url>
50
            <finalize-url>https://payment.app/async/finalize</finalize-url>
51
            <validate-url>https://payment.app/prepared/validate</validate-url>
52
            <capture-url>https://payment.app/prepared/capture</capture-url>
53
            <refund-url>https://payment.app/refund</refund-url>
54
            <!-- This optional path to this icon must be relative to the manifest.xml -->
55
            <icon>Resources/paymentLogo.png</icon>
56
        </payment-method>
57
    </payments>
58
</manifest>
Copied!
Synchronous payments
Synchronous payments are the more simple kind of payments without any further interaction with the user. You have two different kind of options here. Depending on if you have defined a pay-url, you can choose to be informed about - and possibly process - a payment or not.
If you would just like to define another payment method like advanced payment or collect on delivery, where the owner of the shop will manually mark the payment as paid later, you can stop reading this guide here, because no communication with your app is required. The transaction will remain on the status open.
On the other hand, if you define a pay-url, you have the option to respond on this request with a different transaction status, for example authorize, paidor fail. This is useful if you would like to add a payment provider which only need the information the user has already provided in the checkout process and no additional information is required. This could be - for example - a simple credit check for payment upon invoice.
Below you can see an example for a simple answer from your app to mark a payment as authorized. You can see two methods, checkSignature and sign, for both of these see the section Validation. The provided status should be the transistion name for the transaction based on the previous status open.
1
use Symfony\Component\HttpFoundation\Request;
2
use Symfony\Component\HttpFoundation\JsonResponse;
3
use Symfony\Component\Routing\Annotation\Route;
4
​
5
/**
6
 * @Route("/sync/process", name="sync.process", methods={"POST"})
7
 */
8
public function processSynchronousPayment(Request $request): JsonResponse
9
{
10
      // more on this in section "Validation"
11
      $this->checkSignature($request);
12
​
13
      $content = \json_decode($request->getContent(), true);
14
​
15
      // implement your logic here based on the information provided in $content
16
      $response = [ 'status' => 'authorize' ];
17
​
18
      // this returns a json encoded response with the `shopware-app-signature` in the header
19
      return $this->sign($response, $content['source']['shopId']);
20
}
Copied!
Instead of a successful response, you can also provide a failed response with a message (which will be logged) like this:
1
$response = [
2
    'status' => 'fail',
3
    'message' => 'The customer failed to pass the credit check.',
4
];
Copied!
Keep in mind that just by providing a message, the payment will default to status fail.
Asynchronous payments
Asynchronous payments are more complicated and rely on interaction with the user and therefore a redirect to the payment provider. For example, this might be an integration with PayPal or Stripe. The following process applies:
Shopware sends the first pay POST request which is supposed to start the payment with the payment provider. All necessary data is provided: the order, orderTransaction and a returnUrl, where the user should be redirected to once the payment process with the payment provider has been finished. If everything is correct and the payment process is ready to start, the response to this request should be a redirectUrl, where the user is redirected to by Shopware. In case the payment can't be started (for example because of missing credentials for the shop), this can also return a fail status and / or a message.
1
use Symfony\Component\HttpFoundation\Request;
2
use Symfony\Component\HttpFoundation\JsonResponse;
3
use Symfony\Component\Routing\Annotation\Route;
4
​
5
/**
6
 * @Route("/async/pay", name="async.pay", methods={"POST"})
7
 */
8
public function startAsyncPayment(Request $request): JsonResponse
9
{
10
    // more on this in section "Validation"
11
    $this->checkSignature($request);
12
​
13
    $content = json_decode($request->getContent(), true);
14
​
15
    // you can identify the transaction later on with the orderTransactionId
16
    $transactionId = $content['orderTransaction']['id'];
17
​
18
    // implement your logic here based on the information provided in $content
19
    // you should save the transactionId for later identification in the second request and in the user redirection
20
    $response = [ 'redirectUrl' => sprintf('https://payment.app/user/go/here/%s/', $transactionId) ];
21
​
22
    // this returns a json encoded response with the `shopware-app-signature` in the header
23
    return $this->sign($response, $content['source']['shopId']);
24
}
Copied!
The second finalize POST request will be called once the user has been redirected that your app or your payment provider should back to the shop. This second request is only provided with the orderTransaction for identification purposes. The response status value determines the outcome of the payment, e.g.:
Status
Description
cancel
User has aborted the payment at the payment provider's site
fail
Payment has failed (e.g. missing funds)
paid
Successful immediate payment
authorize
Delayed payment
1
use Symfony\Component\HttpFoundation\Request;
2
use Symfony\Component\HttpFoundation\JsonResponse;
3
use Symfony\Component\Routing\Annotation\Route;
4
​
5
/**
6
 * @Route("/async/finalize", name="async.finalize", methods={"POST"})
7
 */
8
public function finalizeAsyncPayment(Request $request): JsonResponse
9
{
10
    // more on this in section "Validation"
11
    $this->checkSignature($request);
12
​
13
    $content = json_decode($request->getContent(), true);
14
​
15
    // you can identify the transaction again with the orderTransactionId
16
    $transactionId = $content['orderTransaction']['id'];
17
    $status = $this->getStatusFromPaymentProvider($transactionId);
18
​
19
    // implement your logic here based on the information provided in $content
20
    // you should save the transactionId for later identification in the second request and in the user redirection
21
    $response = [ 'status' => $status ];
22
​
23
    // this returns a json encoded response with the `shopware-app-signature` in the header
24
    return $this->sign($response, $content['source']['shopId']);
25
}
26
​
27
private function getStatusFromPaymentProvider(string $transactionId): string
28
{
29
    // check with the payment provider here to receive the final status
30
    return 'paid';
31
}
Copied!
Instead of a successful response, you can also provide a failed response with a message (which will be logged) like this:
1
$response = [
2
    'status' => 'fail',
3
    'message' => 'The customer failed to pass the credit check.',
4
];
Copied!
Keep in mind that just by providing a message in either request response, the payment will default to status fail, except if you also provide the status cancel in the finalize request.
Prepared payments
If you would like to not only offer forwarding to a payment provider, but integrate more deeply into the checkout process, with Shopware 6.4.9.0 and later you might like to use prepared payments. This method allows you to prepare the payment already before the order is placed, e.g. with credit card fields on the checkout confirm page. By adding parameters to the order placement request -- in the Storefront, this is the checkout confirm form -- you can then hand your prepared payment handler the parameters to successfully capture the payment when the order is placed.
For this, you have two calls available during the order placement, the validate call to verify, that the payment reference is valid and if not, stop the placement of the order, and the capture call, which then allows the payment to be processed to completion after the order has been placed and persisted.
Let's first talk about the validate call. Here, you will receive three items to validate your payment. The cart with all its line items, the requestData from the CartOrderRoute request and the current salesChannelContext. This allows you to validate, if the payment reference you may have given your payment handler via the Storefront implementation is valid and will be able to be used to pay the order which is about to be placed. The array data you may send as the preOrderPayment object in your response will be forwarded to your capture call, so you don't have to worry about identifying the order by looking at the cart from the validate call. If the payment is invalid, either return a response with an error response code or provide a message in your response.
1
use Symfony\Component\HttpFoundation\Request;
2
use Symfony\Component\HttpFoundation\JsonResponse;
3
use Symfony\Component\Routing\Annotation\Route;
4
​
5
/**
6
 * @Route("/prepared/validate", name="prepared.validate", methods={"POST"})
7
 */
8
public function validatePreparedPayment(Request $request): JsonResponse
9
{
10
    // more on this in section "Validation"
11
    $this->checkSignature($request);
12
​
13
    $content = json_decode($request->getContent(), true);
14
​
15
    // you may validate your payment now with e.g. this data
16
    $yourPaymentReference = $content['requestData']['myAppPaymentId'];
17
    $cartAmount = $content['cart']['price']['totalPrice'];
18
​
19
    // this helps you later identify the payment reference in your capture call
20
    $response = [ 'preOrderPayment' => ['paymentId' => $yourPaymentReference] ];
21
​
22
    // this returns a json encoded response with the `shopware-app-signature` in the header
23
    return $this->sign($response, $content['source']['shopId']);
24
}
Copied!
If the payment has been validated and the order has been placed, you then receive another call to your capture endpoint. You will receive the order, the orderTransaction and also the preOrderPayment array data, that you have sent in your validate call.
1
use Symfony\Component\HttpFoundation\Request;
2
use Symfony\Component\HttpFoundation\JsonResponse;
3
use Symfony\Component\Routing\Annotation\Route;
4
​
5
/**
6
 * @Route("/prepared/capture", name="prepared.capture", methods={"POST"})
7
 */
8
public function capturePreparedPayment(Request $request): JsonResponse
9
{
10
    // more on this in section "Validation"
11
    $this->checkSignature($request);
12
​
13
    $content = json_decode($request->getContent(), true);
14
​
15
    // you may capture your payment now with e.g. this data
16
    $yourPaymentReference = $content['preOrderPayment']['paymentId'];
17
    $orderAmount = $content['order']['price']['totalPrice'];   
18
    
19
    // you can provide any status here that the payment should have later on in Shopware
20
    $response = [ 'status' => 'paid' ];
21
​
22
    // this returns a json encoded response with the `shopware-app-signature` in the header
23
    return $this->sign($response, $content['source']['shopId']);
24
}
Copied!
Keep in mind that if the integration into the checkout process does not work as expected, your customer might not be able to use the prepared payment. This is especially valid for after order payments, since there the order already exists. For these cases, you should still offer a traditional synchronous / asynchronous payment flow. Don't worry, if you have set the transaction state in your capture call to anything but open, the asynchronous payment process will not be started immediately after the prepared payment flow.
Refund
With Shopware 6.4.12.0, we have also added basic functionality to be able to refund payments. Your app will need to register captured amounts and create and persist a refund beforehand for Shopware to be able to process a refund of a capture.
Similar to the other requests, on your refund call you will receive the data required to process your refund. This is the order with all its details and also the refund which holds the information on the amount, the referenced capture and, if provided, a reason and specific positions which items are being refunded.
1
use Symfony\Component\HttpFoundation\Request;
2
use Symfony\Component\HttpFoundation\JsonResponse;
3
use Symfony\Component\Routing\Annotation\Route;
4
​
5
/**
6
 * @Route("/refund", name="refund", methods={"POST"})
7
 */
8
public function refundPayment(Request $request): JsonResponse
9
{
10
    // more on this in section "Validation"
11
    $this->checkSignature($request);
12
​
13
    $content = json_decode($request->getContent(), true);
14
​
15
    // you may capture your payment now with e.g. this data
16
    $captureId = $content['refund']['captureId'];
17
    $refundAmount = $content['refund']['amount']['totalPrice'];
18
    
19
    // you can provide any status here that the refund should have later on in Shopware
20
    $response = [ 'status' => 'refunded' ];
21
​
22
    // this returns a json encoded response with the `shopware-app-signature` in the header
23
    return $this->sign($response, $content['source']['shopId']);
24
}
Copied!
Validation
All of the payment requests you receive from Shopware should be checked for a correct signature and the responses should be signed as well. You should be familiar with the Setup process from the App base guide, as this validation is very similar.
App Base Guide
When receiving a payment pay or finalize request, you need to first validation the signature of the request. This signature is provided in the shopware-shop-signature header, which contains a cryptographic signature of the query string. Therefore you need to calculate the sha256 hmac based on the encoded JSON and the secret you have saved during the app registration.
1
use Symfony\Component\HttpFoundation\Request;
2
​
3
private function checkSignature(Request $request): void
4
{
5
    $requestContent = json_decode($request->getContent(), true);
6
    $shopId = $requestContent['source']['shopId'];
7
​
8
    // get the secret you have saved on registration for this shopId
9
    $shopSecret = $this->getSecretByShopId($shopId);
10
​
11
    $signature = $request->headers->get('shopware-shop-signature'):
12
    if ($signature === null) {
13
        throw new Exception('No signature provided signature');
14
    }
15
​
16
    $hmac = hash_hmac('sha256', $request->getContent(), $shopSecret);
17
    if (!hash_equals($hmac, $signature)) {
18
        throw new Exception('Invalid signature');
19
    }
20
}
Copied!
When sending your response, you also need to add a signature to the header of the request. This signature needs to be provided in the shopware-app-signature header. This also needs to be calculated as a sha256 hmac based on the encoded JSON and the secret you have saved during the app registration.
1
use Symfony\Component\HttpFoundation\Request;
2
use Symfony\Component\HttpFoundation\JsonResponse;
3
​
4
private function sign(array $content, string $shopId): JsonResponse
5
{
6
    // this encodes the json automatically
7
    $response = new JsonResponse($content);
8
​
9
    // get the secret you have saved on registration for this shopId
10
    $shopSecret = $this->getSecretByShopId($shopId);
11
​
12
    $hmac = \hash_hmac('sha256', $response->getContent(), $secret);
13
    $response->headers->set('shopware-app-signature', $hmac);
14
​
15
    return $response;
16
}
Copied!
API docs
Payment Reference
Configuration
Content
Last modified 18d ago
Copy link
Edit on GitHub
Contents
Prerequisites
Manifest configuration
Synchronous payments
Asynchronous payments