Saleor 3.13: updated Transactions API, support for Payment Apps, and Payment App Adyen

Core API 3.13

See the following changelog for a complete list of changes in this release: changelog 3.13.0. Now, we'll quickly go through the most important updates.

Improved transactions handling

We've rolled out a preview of a completely revamped transactions API including new types, mutations, and webhooks. Let's look closely at some of them.

transactionEventReport is a new mutation that can be used to report events for a transaction. It's a more intuitive and powerful replacement for transactionUpdate. For example, let's take a scenario where the user submits their card to pay, and it gets charged, but the user requests a refund. Now we're able to create a history of changes to the transaction using the new transactionEventReport mutation and in this case, we'll have a list of events:

Each of them with metadata: time, message, PSP reference, and available actions that can be taken at a certain stage. Notice the INFO event – it can be used to add more context and additional information to your payment flows. You can find all kinds of events here.

Note that apps don't need to recalculate the amounts anymore because, with transactionEventReport, Saleor does it for you. For example, after Saleor receives $100 CHARGE_SUCCESS and $25 REFUND_SUCCESS events, chargedAmount will be set to $75 and refundedAmount to $25 – no manual calculations required.

New transaction webhooks

Moreover, new webhooks and webhook subscriptions have been added:

• TransactionChargeRequested – Sent when transaction charge is requested.
• TransactionRefundRequested – Sent when transaction refund is requested.
• TransactionCancelationRequested – Sent when transaction cancelation is requested.

Together with the transactionEventReport mutation, these make it possible to handle even the most complex e-commerce flows with ease. See the docs for transactions.

Support for Payment Apps

We've also released a preview for Payment Apps. Payment Apps are a completely modernized approach to handling payments with any provider via Saleor GraphQL API. You use GraphQL to handle different flows and actions, including but not limited to pre-authorization, charging the customer, split payments, refunds and partial refunds, and many others.

Using Payment Apps is as simple as calling a few mutations, for example:

mutation InitializeAdyenAppMutation {
  paymentGatewayInitialize(
    id: "Q2hlY2tvdXQ6YWY3MDJkMGQtMzM0NC00NjMxLTlkNmEtMDk4Yzk1ODhlNmMy"
    amount: 54.24
    paymentGateways: [{ id: "app.saleor.adyen" }]
  ) {
    gatewayConfigs {
      id
      data
    }
  }
}

Then, Saleor processes the request and sends a synchronous webhook to the correct Payment App. The really important part is that Saleor now automatically creates and updates transactions with the appropriate status and amounts based on the requests and Payment App's responses!

You'll find the diagrams of the Payment Apps flow and lots of detailed information in the Payment Apps docs.

Payment Apps vs Payment Plugins

New mutations, new webhook subscriptions, and Payment Apps all together are meant to replace Payment Plugins. They're way more powerful, too! The table below shows how the new Payment Apps approach compares with Payment Plugins.

	Transactions API	Payment Plugins
Can be used with checkout	✅ Yes	✅ Yes
Can be used with order	✅ Yes. Can attach payments to an existing order.	❌ No
Split payments	✅ Yes	❌ No
Possibility to update the payment when it's changed on the payment provider side (for example, someone made a charge/refund in the payment provider dashboard)	✅ Yes	❌ No
Tracking history	✅ Yes. TransactionItem has an events history for each action. The events are visible in Saleor Dashboard.	⚠️ Somewhat; lack of granularity.
Providing context to processed payments and actions	✅ Yes. TransactionItem and TransactionEvent have name, message, pspReference and externalUrl thatp provide context to transactions and actions. The fields are visible in the dashboard.	⚠️ Somewhat; most fields are not visible in the dashboard, API-only.

Adyen Payment App

What does it take to build your Payment App? You can integrate with an arbitrary Payment Provider by implementing just a few webhooks in your app:

• PaymentGatewayInitialize - Triggered when a customer requests the initialization of a payment gateway.
• TransactionInitialize - Triggered when a customer requests the initialization of a payment processing.
• TransactionProcess - Triggered when a customer requests processing the initialized payment.

That's it! You can read all about the Transaction Webhooks in our docs.

In the upcoming months, we'll be releasing Saleor Payment Apps for multiple popular payment providers. Today, we're proud to announce the first one: Adyen. You can find the Adyen App in Saleor App Store.

You'll find all the information required to integrate Saleor Payment App Adyen on your website or mobile app in the docs.

Bulks updates

Saleor 3.13 adds three new mutations related to mass updates:

• stockBulkUpdate
• productBulkCreate
• customerBulkUpdate

These new mutations together with productVariantBulkCreate, productVariantBulkDelete, and productVariantBulkUpdate complete the list of basic bulk operations. We believe they'll come in handy for many users and different scenarios. Moreover, they allows us to build more sophisticated user experiences such as data-grid management and inline editing in Saleor Dashboard.

---

We're excited to see what our users can build with the new Transactions, support for Payment Apps, and other changes in Saleor 3.13! We're looking forward to your feedback, ideas, and suggestions.

Follow our Twitter and sign up for our newsletter to stay up to date with the latest info about Saleor.

Cheers!

– The Saleor Team