MFA is now mandatory in Console

You must now use multi-factor authentication (MFA) to access Console.

If you do not currently use MFA: next time you log into Console, you will be prompted to configure it and will not be able to access Console until you complete this configuration.

If you do have MFA configured, you will be required to complete an MFA challenge before continuing into Console.

Mock service for account holder verification

You can now test account holder verification in sandbox. To test specific results, input specific name and IBAN combinations when you send a POST or GET request to the sandbox server.

More sweeping frequencies

You can now opt to sweep money from your merchant account more frequently than daily, weekly or fortnightly. The new sweeping frequencies are:

• hourly
• every three hours
• every six hours
• every twelve hours

Configure your sweeping frequency using the API, or in Console using the Manage funds tab inside the Merchant accounts page.

New Mobile SDK versions

The latest version of the Android SDK and iOS SDK is now 4.1.1.

The latest version of the React Native SDK is now 3.1.0.

They fix an issue with the UI in which users would be able to interact with elements from the background, even underneath the bottom sheet. They also include general updates and improvements.

Account holder verification fields in payout webhooks

Payout webhooks in the EU, where the beneficiary is an external account, now include fields which indicate the result of account holder verification (in which we match the details given in a payout to the name that is on file at the bank.)

Conversion-based availability detection

We can now detect bank downtime even when providers are returning incorrect HTTP error codes, eg 400s instead of 500s -- or when they don’t return any error codes at all (for example, if their app is unavailable).

When we detect unavailability, affected banks will be automatically greyed out at provider selection.

New payment cancellation

In the UK, Ireland and now Germany, payments can be cancelled up to, and at, the authorizing status.

Across all geographies, when you call the /cancel endpoint to attempt to cancel a payment, you now receive a 202 or 400 response depending on whether the endpoint could be called successfully. A 202 response means that we will attempt to cancel the payment, but does not guarantee that a payment will be cancelled.

The final outcome is communicated via webhooks: the payment may fail or execute as normal. If a payment cannot be cancelled, you now also receive a payment_cancellation_failed webhook to inform you of this.

Payments table changes in Console

There are multiple changes to the way that the Payments table displays in Console:

• Refreshed UI
• You can now add metadata to a refund in the same way that you can for a payment
• When you refund a specific payment, the new View refund details button takes you to the refund in the payments table
• The table is now more accessibly designed thanks to easier keyboard navigation
• The Payment ID column has been renamed to ID. For refunds, the ID that displays is the ID of the refund, not the ID of the payment that was refunded. The transaction ID remains unchanged

Test redirect page for new hosted page

You can now test the new hosted page in a webview using the test redirect page.

Max_wait_for_result field in hosted_page object

When using the hosted_page object inside the Create payment request, you can now set the maximum period to wait before displaying a result screen.

Merchant account name change

It is now possible to change the name of your merchant account. Contact us to enable this feature.

expires_at field in payment_disputed webhook

When you receive a payment_disputed webhook, you now receive a field that informs you when the dispute expires.

New Mobile SDK versions

The newest versions of Android, iOS and React mobile SDKs have been released. The user experience is improved, with new functionalities for retrying payments and simplified returning user journeys.

onBankRedirect callback

If you are using the Web SDK in a webview, use the onBankRedirect callback. This callback passes the redirection URL back to your app so it can open the link in an external browser. This ensures that app-to-app flows work correctly.

Ad hoc business account payouts

You can now make a one-off payout into your business account from your merchant account to your business account.

To make a one-off, or ad hoc, business account payment, go to the Merchant Accounts tab inside your app and navigate to Manage funds.

Changed behaviour for refunds

You can now create a refund from the authorized status onwards, to happen automatically as soon as the payment settles.

The refund will have the pending status until the payment settles. All queued refunds are initiated in the order that the corresponding payments settle.

Payment_funds_received webhook

You now receive this webhook when a Direct Debit payment arrives in your merchant account. Note that the payment can still be reversed at this stage.

Docs || API reference

Verified payouts with name and transaction verification

Verified Payouts enables you to pay out to a known, verified beneficiary. For example, you may want to make a payout to the same bank account previously used to make a deposit, even if the user initially paid with a debit card.

You can use this feature to verify an account holder's name and/or a particular transaction within certain parameters.

Docs // API specs

Reversal fields visible in GET Payment responses

If you make a GET Payment request and the payment in the response has been reversed, you now receive reversed_at and reversal_reason in the response.

Docs // API specs

New business_client option inside submerchants object in Create Payment endpoint

If you are a PSP, you can now specify a business_client inside the Create Payment request. This enables you to specify and include information about a merchant that you are partnered with, when a user makes a payment to that merchant.

API specs

Statement_reference for mandates

You can now supply a custom reference for a mandate that you create, for easier reconciliation and to contextualise a payment on your user's bank statements.

Docs // API specs

Web SDK v1

Web SDK v1 is a new version of the Web SDK. In Web SDK v1, the Web SDK is initialized without initiating a payment.

When the user taps the Pay button, we invoke the onStartFlow() callback. When this happens, you can create the payment and pass it to the Web SDK.

Read the migration guide for more information.