Skip to main content

ยท 3 min read

New featuresโ€‹

๐Ÿฆ With Multiple Accounts, company account holders can create additional accounts without repeating onboarding or Know Your Business (KYB) processes.

Improvementsโ€‹

๐Ÿšš We've added LaPosteTracked as a new shipping method for international card deliveries. This gives cardholders outside of France a reliable way to track their card's delivery from our printing hub.

๐Ÿ“„ We've made it easier to reconcile payments by allowing you to use structured and unstructured formats for invoice references in transactions. For SEPA Credit Transfers, use the labelType field to choose the reference standard and the label field for the value. When you retrieve transaction data, this value will be in the transaction.label. You can also specify the ogmVcs type for Belgian OGM VCS references.

Verification of Payee (VoP) updatesโ€‹

โš ๏ธ The following updates are currently available in our Sandbox environment and will be released to the Live environment on October 9.

๐Ÿ’ธ initiateCreditTransfers endpoint updatesโ€‹

๐Ÿ“… scheduleStandingOrder endpoint updatesโ€‹

  • When calling the scheduleStandingOrder mutation, we'll automatically verify the beneficiary's details and display the results in the consent screen.
  • A new beneficiaryVerificationResult field has been added to the ScheduleStandingOrderSuccessPayload.

๐Ÿ“’ You can now retrieve the beneficiaryVerificationResult using the transaction, transactions, standingOrder, and TrustedBeneficiary queries.

VoP rolloutโ€‹

๐Ÿ“ฅ Starting October 5, we'll automatically handle all incoming VoP requests from other Payment Service Providers (PSPs). Beneficiary details will be verified, and the result will be returned to the PSP before funds are transferred into a Swan account. No action is required from you.

๐Ÿƒ On October 9, company accounts will be opted out of VoP for bulk credit transfers by default, while individual accounts will be opted in. You can change the setting for bulk transfers with the updateAccountSettings mutation, once the verifyBeneficiary mutation is implemented.

๐Ÿ“ก On October 9, the verifyBeneficiary mutation will be available to verify beneficiary details before initiating credit transfers. Use the save parameter to add a trusted beneficiary when the returned token successfully initiates the credit transfer.

๐Ÿ“ฉ On October 19, the save parameter of the verifyBeneficiary mutation will default to false.

Upcoming breaking changesโ€‹

๐Ÿ›‘ Starting October 9, the initiateCreditTransfers mutation will return a new rejection reason if the BeneficiaryVerificationToken was already used to initiate another credit transfer.

โœ”๏ธ Starting October 31, the beneficiaryVerification query will be deprecated. Use the verifyBeneficiary mutation instead to ensure uninterrupted service.

ยท 3 min read

Improvementsโ€‹

๐Ÿ›’ Improvements to merchant profiles and merchant payment methods, and the requestMerchantProfile and requestMerchantProfileUpdate mutations:

  • The Testing APIs simulateMerchantProfileRequestOutcome and simulateMerchantPaymentMethodRequestOutcome mutations now support the new WaitingForInformation status and return a list of verificationRequirements.

  • A new optional field expectedMerchantProfileAdditionalInformation is now available at the projectInfo level. This field allows you to customize information collected for merchant profiles when configured as part of your merchant feature approval process.

    The information can then be provided using the additionalInformation field in merchant profiles and in the requestMerchantProfile and requestMerchantProfileUpdate mutations.

  • The invoiceExample field has been deprecated.

  • The expectedMonthlyPaymentVolume, merchantWebsite, socialNetwork, supportWebsite, and termsAndConditions fields are being deprecated.

  • We've deprecated the rejectReasons field and replaced it with rejectionReasons.

API updatesโ€‹

Upcoming breaking changesโ€‹

๐Ÿ“ก Starting October 9, bulk SEPA Credit Transfers from individual account holders will be rejected if verification tokens aren't included in the payment initiation. You must either implement the verifyBeneficiary mutation (recommended) or restrict bulk credit transfer access to company accounts only. This change applies to both Live and Sandbox environments.

๐Ÿ’ณ On October 16, the CardUrl field will be removed. Use cardMaskedNumber, expiryDate, and cardDesignUrl instead.

๐Ÿ›’ On October 16, the following merchant onboarding and payment methods breaking changes will take effect:

  • A new WaitingForInformation status and verificationRequirements list will be available to show missing information on merchant profiles and payment methods. Submit the required information using the requestMerchantProfile or requestMerchantProfileUpdate mutations.
  • A new supportingDocumentCollections field will also be available at the merchant profile level for providing required documents.
  • The invoiceExample, expectedMonthlyPaymentVolume, merchantWebsite, socialNetwork, supportWebsite, termsAndConditions will be removed. Use expectedMonthlyMerchantProcessingVolume, merchantWebsiteUrl, socialNetworkUrl, supportWebsiteUrl, and termsAndConditionsUrl instead.
  • rejectReasons will be removed for card payment methods.
  • rejectionReasons for Rejected merchant profiles and merchant payment methods will become mandatory in Testing APIs simulateMerchantProfileRequestOutcome and simulateMerchantPaymentMethodRequestOutcome.
  • Dynamic rolling reserve changes and maximum payment amount limits will be introduced at the merchant payment method level to mitigate risk. Subscribe to the MerchantPaymentMethod.Created and MerchantPaymentMethod.Updated webhooks for these updates.

๐Ÿ’ธ Effective October 19, we're introducing updates to the initiateCreditTransfers endpoint to improve its usability and clarity:

  • The save parameter will default to false.
  • The mode parameter will be a required field. The default value is set to Regular.
  • The isMyOwnIban and beneficiaryId input fields will be removed.
  • The API will return a ValidationRejection error instead of ForbiddenRejection when an input contains invalid data.

Updateโ€‹

๐Ÿงญ Starting October 21, card-issuing spending limits will be aggregated at the hour level. To calculate card spending limits, each payment is recorded at the start of the hour. The rolling period resets every hour. This change applies to cards with daily, weekly, and monthly spending limit periods.

ยท One min read

New featuresโ€‹

๐Ÿ“– Get a head start on what's next. We've added a Preview section to our documentation, giving you early access to our features. Use these previews to plan your future roadmap. Note that functionality may change before the official release.

Improvementsโ€‹

โน๏ธ You can now cancel merchant SEPA Direct Debit payments using the cancelMerchantPayment mutation. Refer to the availableToCancel balance to check if a specific payment can be canceled.

๐Ÿ” Use the isCancelable field to verify whether scheduled account funding transactions are eligible for cancellation.

API updatesโ€‹

Upcoming breaking changesโ€‹

๐Ÿ”„ Starting October 1, we're removing the paymentId field from the initiateSepaDirectDebitMerchantPayment mutation. Instead, retrieve the ID from the merchantPayment field, which now returns the Merchant Payment object. We're also deprecating the paymentId field.

โš–๏ธ Starting October 31, the taxIdentificationNumber will be a mandatory field at onboarding when an account holder's residency country does not match the accountCountry. This is to comply with CRS (Common Reporting Standard) regulations. For example, Spanish residents opening French accounts will need to provide their tax identification number.

ยท One min read

New featuresโ€‹

๐Ÿ’ณ Payment Control now supports โ‚ฌ0 authorizations and credit authorizations, identifiable with TransactionSide! as Credit. Activate this feature from your Dashboard > Developers > Payment control.

๐Ÿ”‘ Idempotency is now available for initiateCreditTransfers. Add an idempotency key to your transfer queries to improve reliability and prevent duplicate transactions.

๐Ÿ“ฅ You can now export transaction data in .csv format from your Dashboard or with the API by calling the exportTransactionData mutation.

Improvementsโ€‹

๐Ÿง‘โ€๐Ÿคโ€๐Ÿง‘ Server-to-server consent is now available for all account membership mutations, enabling you to reduce manual operations and scale more easily.

๐Ÿ”ข A new Service section is now available in your Dashboard > Insights. This section provides essential data on your KYC and Transaction Monitoring operations, including processing volumes and SLA performance. Related metrics have been moved from the Onboarding section to centralize this information.

ยท One min read

New featuresโ€‹

๐Ÿ“– Learn about the new Verification of Payee regulation, its impact on your users, and how you can update your Swan integration to improve your payment experience.

Improvementsโ€‹

๐Ÿ‘ฅ Get more balance information for booked transactions using BookedTransactionStatusInfo.balanceAfter. This object provides:

  • amount - replaces the existing BookedBalanceAfter.amount (see upcoming breaking changes).
  • sequenceNumber - new account-level transaction counter for new transactions (historical transactions show null).

๐Ÿงญ Customize column width on all Dashboard pages to make the data easier to read.

๐Ÿช Two new webhooks are now available to update you on rolling reserve changes. TransactionRollingReserve.Updated is triggered when the release date is changed, and TransactionRollingReserve.Released will indicate that the reserved funds are now available.

API updatesโ€‹

Upcoming breaking changesโ€‹

๐Ÿ“„ Starting August 28, we'll start using these new, already available enum variables: USPersonStatusDeclaration and ProofOfBusinessActivity for SupportingDocumentPurpose, and W9, W8, and CertificateOfLossOfNationality for SupportingDocumentType.

๐Ÿ‘ฅ Starting December 31, the bookedBalanceAfter field will be removed from the transaction query. Please use the balanceAfter.amount on BookedTransactionStatusInfo.

ยท 2 min read

New featuresโ€‹

๐Ÿ”— Send a SEPA Direct Debit B2B mandate registration link to users with the canInitiatePayments permission. Get the link from your Dashboard > Data > Accounts page.

Improvementsโ€‹

๐Ÿ’ณ One-off single use virtual cards now default to expiring 30 days after creation. This applies when SpendingLimitPeriod is set to Always in the addSingleUseVirtualCard and addSingleUseVirtualCards mutations. You can change this by setting a custom cardContractExpiryDate.

๐Ÿงญ Transaction confirmation documents now follow a new, more readable naming convention that includes the document language. The new format is: TransactionConfirmation_[transactionId]_[documentLanguage].

Updatesโ€‹

๐Ÿชช Starting August 7, we'll recommend QES as the identification method for German accounts, replacing the current Expert level. If you use Auto, no action is needed. This change will apply automatically.

API updatesโ€‹

Upcoming breaking changesโ€‹

๐Ÿ›‘ Starting August 18, the initiateCheckMerchantPayment mutation will return a new rejection: MerchantPaymentAlreadyExistsRejection. This occurs when you try to create a merchant payment, but the CMC7 value is already used by an existing payment that hasn't been Rejected or Canceled. If the existing payment with the same CMC7 was Rejected or Canceled, your mutation will still succeed.

๐Ÿ’ณ Starting August 21, refund transactions will be linked to the paymentId of their original debit authorization when referenced by merchants. This change affects you only if you expect debit clearing transactions on a debit authorization.

ยท One min read

API updatesโ€‹

Upcoming breaking changesโ€‹

๐Ÿ” Starting July 10, failed consent attempts will trigger the Consent.Failed webhook. Previously, failed consents triggered Consent.Granted, due to a bug. The new webhook is already available in your Dashboard.

โœ‰๏ธ Starting July 21, the shippingProvider field in PhysicalCardToActivateStatusInfo and PhysicalCardRenewedStatusInfo will be migrated from a String to an ENUM. On the same day, the shipping provider values La Poste and CORREOS will be removed.

ยท One min read

Improvementsโ€‹

๐Ÿงญ Account statement documents now follow a new, more readable naming convention that includes the document language. The new format is: AccountStatement_[ProjectName]_[AccountNumber]_[period]_[documentLanguage].

๐Ÿ‘ซ Account member invitations with a ConsentPending status will now expire if the inviter doesn't provide consent before the consent period ends. This automatically changes the account membership status to Disabled, allowing you to inform the user to send a new invitation.

  • If you're subscribed to the AccountMembership.Updated webhook, you'll receive a notification when the membership is Disabled.
  • When querying AccountMembershipDisabledStatusInfo, you'll see the reason InvitationExpired.

โœ๏ธ You can now use CheckMerchantPayment to track the statuses and balances of French check payments.

API updatesโ€‹

Upcoming breaking changesโ€‹

โš ๏ธ Starting July 1, the shippingProvider field in PhysicalCardToActivateStatusInfo and PhysicalCardRenewedStatusInfo will be migrated from a String to an ENUM. Please note that the shipping providers La Poste and CORREOS will soon be deprecated.

๐Ÿ’ถ On August 1, we're removing the merchantPayment field in the InitiateCheckMerchantPaymentSuccessPayload, use checkMerchantPayment instead. We're also deprecating merchantPayment.

ยท 2 min read

New featuresโ€‹

๐Ÿ’ณ You can now disable users from updating their card settings in Swan's Web Banking from your Dashboard > Web banking settings tab. When disabled, users with the CanUpdateCards permission can only update card limits through your product, not Web Banking.

Improvementsโ€‹

๐Ÿงญ We've made several improvements to your Dashboard:

  • The Dashboard search now returns more accurate results. Results automatically narrow as you type and add more details. This update is available on the Account Holders, Onboarding, Account, Account Memberships, and Capital Deposits pages.
  • Filters have a new look across all Dashboard pages to help you find data more efficiently. We added quick filters for all verification statuses on the Account Holders page based on user feedback. We removed the Verifications page because the new filters provide the same information in a more accessible way.

๐Ÿ” We've added new filters to enhance searching for transaction information by amount and execution date in the API:

  • Amount filters: we added isAboveAmount and isBelowAmount. We also updated the amount filter to return an exact match. These filters are now cumulative and will replace the current amount field in the transactions search filter (see upcoming breaking change).
  • Execution date filters: we added isAfterExecutionDate and isBeforeExecutionDate.

โœ๏ธ The requestMerchantPaymentMethods mutation now validates your SEPA Creditor Identifier (SCI) when you request SEPA Direct Debit. If the SCI is invalid, the mutation will reject it, helping you avoid blocked transactions in the future.

๐Ÿ“ You can now retrieve all transactions initiated by a standing order using the standingOrder.transactions query.

API updatesโ€‹

Upcoming breaking changesโ€‹

๐Ÿ‘ฅ Starting June 19, the amount field will be removed from the transactions search filter. Please use the amount filters to refine your search.

๐Ÿ’ธ Starting June 19, the beneficiaryId and isMyOwnIban input fields will be removed from the initiateCreditTransfers mutation. The isMyOwnIban field will become optional.

๐Ÿ›‘ Starting June 19, a new rejection type, ValidationRejection, will be used to validate an input in the initiateCreditTransfers mutation.

๐Ÿšซ Starting June 19, calls to scheduleStandingOrder with an invalid reference will be rejected. See the API reference for the regex pattern.

ยท One min read

New featuresโ€‹

๐Ÿ“ฅ You can now export account data in .csv format from your Dashboard or with the API by calling the exportAccountData mutation.

Improvementsโ€‹

๐Ÿชช Auto identification is now smoother. To automatically skip the identification process for eligible users on projects configured to bypass it, add the accountMembershipId to the authorization URL when inviting account members.

๐Ÿค To protect you and the merchant from fraud, merchant payments may now have a paymentAmountLimit that applies to each individual transaction. This limit may be applied during the review of the merchant payment method or later, based on risk factors. It's available in the merchantPaymentMethod type in the API, for Card, SEPA Direct Debit (Core and B2B), and French check payments. Setting a limit will trigger a MerchantPaymentMethod.Updated webhook.