Hotfix for 3DS
FixResolved an issue with confirming 3DS authentication. This was causing intermittent issues that resulted in false failed payments.
Updates, improvements, and fixes
Resolved an issue with confirming 3DS authentication. This was causing intermittent issues that resulted in false failed payments.
Various Adyen fixes have been made that impact onboarding, voiding, and the address information being passed properly to Adyen during a card payment. These fixes will be ongoing over the coming weeks.
While making that change, we also noticed that we were not sending the full address information to Stripe. This is now resolved.
The Net Funding capability is supported per payment method instead of a single setting across the entire account. This is especially helpful in scenarios where the merchant wants to pass through card fees to the payer but absorb the ACH fees. In this case, card transactions can have Net Funding enabled on to avoid having the payer fees deposit into the merchant's account. Meanwhile, the ACH transactions can be gross funded to the merchant and have fees debited later during the billing cycle.
Fixed an issue with the mishandling of the billing first and name when executing a payment on CyberSource. Adding an extra space at the end of the billing name would cause a blank last name to be sent to CyberSource which would throw an error.
We fixed issues with the Stripe 3DS implementation where our system was not properly handling the reuse of card tokens in certain 3DS scenarios.
The flow should be as follows - Pass in a returnUrl and the user will be prompted with 3DS if the processor/bank so chooses. Don't pass in a returnUrl and either a) the payment succeeds because 3DS isn't supported/required on the card b) the payment succeeds because 3DS is only required the first time and it was already successful or c) the payment fails because 3DS is always required.
In some cases, we've broken the first part where passing in a returnUrl can error if the card always requires 3DS.
A new "billing" permission has been added to user accounts. It controls who can see the pricing tab on the account and the Billing menu option. The permission will be granted to all current users by default to avoid disrupting existing users.
The account validation flag on the POST /tokens payload is now deprecated.
The POST /accountValidations endpoint has been added to accept ACH information for account or account-name validation (see the accountValidationMethod property).
Pricing has been updated to support this functionality: account number + name validation is $0.60, while account number validation remains $0.20. See the full pricing list at dhango.com/terms or dhango.com/pricing.
The metadata from a processed check is added to the transaction for easy reconciliation. This includes adding the username to the transaction metadata and populating the PaidCustomers collection.
The PaidCustomers and PaidInvoices collections have been added to the transaction and terminal session objects. The purpose is to provide structured metadata on the payment to identify the customers and invoices for which the payment was made. Both of these are optional collections.
We are deprecating the CustomerId on the transaction requests and responses in place of using the Customers collection. The CustomerId field will still be supported into the middle of October, at the latest.
A date range search has been added to the webhook events page to allow you to search back through history for all past events.
The POST /authorize endpoint supports a $0 authorization as a way to test a card and tokenize it before processing payments. This is especially helpful in a 3DS flow where the $0 authorization triggers user authentication so payments can be subsequently processed without user interaction. The Stripe integration uses the SetupIntent to support this flow.
FTNI onboarding has been modified to support multiple "settlement" accounts on a single merchant so a user can choose the account of their choice for settlement of the check transaction.
Various onboarding changes have been made for Adyen including the cron expression for sweeps is configurable through the platform level setting, the reference is being set on the balance account for easy readability in the Adyen dashboard, and the support phone and email are being set on sole proprietorships.
Line items on the transaction no longer allow a quantity of zero.
The application update flow lets you request that a merchant agree to the latest terms. This is especially useful when your company has revised its terms to switch to a new payment provider.
We have released localization support for Spanish on the sign up, dashboard, and API. All 3 of these operate in different ways.
The localization on the sign up form gives the applicant the option to change their preferred language.
The My Profile page in the dashboard saves the user's language preference so their choice is the default the next time they login.
The API requires the culture header value to be set. Once this is set, all error messages are translated to the specified culture with the default being English if the culture is not specified or not found.
We will continue to add support for additional languages as we move into other regions across Europe and beyond.
We have completely redesigned the sign up application for better usability and a cleaner layout for the applicant. We have also added support for more languages. We have also updated the logic for government entities so the individuals are no longer prompted for a personal tax identifer or a date of birth.
$0 authorizations are now supported on Authorize.net. This required a different call to generate a customer profile record.
There were instances where Adyen was prompting for a 3DS verification even though no returnUrl was passed in by the platform. This has been addressed to never request 3DS verification when there is no returnUrl.
We are now expanding our EU coverage. More specifically, the additional countries include Austria, Denmark, France, Germany, Ireland, Luxembourg, Netherlands, Norway, Spain, Sweden, and Switzerland. This release supports processing in Euro with card and SEPA. Over the coming days, additional releases will roll out with additional support in the UI to match the backend upgrades. We will follow this over the next few weeks with additional language support for these local regions.
Yet another 3DS fix is included in this release for Stripe. This is related to a flag we were setting that was triggering too many 3DS challenges. That flag is no longer being set so 3DS challenges should only appear for those cards where it is required.
Adyen reconciliation is upgraded to use the payout report. This gives our system a more reliable way of tracking payouts, especially those that include refunds.
The transaction download feature now downloads directly through the browser instead of sending an email to the user.
We simplified the configuration for check acceptance at the platform level by removing unnecessary options on the setup screen.
The Stripe integration was streamlined to avoid extra API calls to Stripe during the payment process. This was done for two reasons. The first reason was to increase throughput of the system. The second reason was that this was done as a part of refactoring to fully support off_session (using the Stripe term) 3DS payments to accompany an earlier update. dhango tokens can now be used off_session once the payer has authenticated the payment method the first time.
There was a bug causing issues with the PayPal Payflow Pro integration that would result in an "Invalid Amount" error when attempting a payment using a culture other than "en" or "en-US". That issue has now been resolved.
Performance improvements were implemented to speed up throughput on crucial endpoints such as POST /transactions/pay. Load testing in the sandbox environment shows a 20% improvement in throughput with a 46% reduction in response time. We will continue to monitor these changes in the sandbox environment before pushing them to production.
Various small enhancements are included in this release.
The prebuilt JS form now supports Spanish.
Support has been added for Diners Club cards.
The sign up form validation now requires exactly one signatory.
A timezone mismatch in batch scheduling prevented all transactions from being included in the intended Third Party Sender batch. As a result, some transactions were deferred and were not included until the following day. This issue is now resolved.
We've rebuilt the dashboard from the ground up with a new architecture designed for better performance and maintainability.
To minimize disruption, we've kept the familiar workflows and layouts you're used to on most pages—so there's no learning curve. At the same time, we've made targeted usability improvements on key pages including:
Adyen webhook events for negative-balance notifications are processed. When a Top Up is attempted, these events trigger an email to users with Risk permissions.
Various 3DS fixes were deployed. One fix was to ensure dhango is not masking error messages that are returned from the processor. We are also returning more descriptive errors to the user if they are reattempting a 3DS authentication with the same exact link that was previously used to confirm a payment.
Any failed 3DS transactions now appear in the dashboard search results under "Rejected".
Adyen's v4 webhook format is now supported.
PATCH /transactions/{id}/metadata has been added to allow for updating of metadata on a transaction for a limited time after the initial creation of the transaction.
Adyen v4 onboarding is now supported along with Canadian bank debits which are referred to interchangeably as ACSS in dhango documentation and EFT in Adyen documentation.
We're excited to support New Zealand and the United Kingdom in addition to support for the United States, Canada, and Australia. This release includes onboarding for merchants in New Zealand and United Kingdom and tokenization and processing for New Zealand Direct Debit and BACS.
In addition, the GET /accounts API endpoint has been deprecated in favor of a new endpoint that removes the need for a duplicate accountKey. The response model now contains the identifier from the underlying processor (e.g. Stripe Connect ID). The original GET /accounts/{accountKey} endpoint will continue to operate as normal for backwards compatibility.
Infrastructure is being added to support the upcoming feature that allows for application updates. The functionality will be exposed to the users once the full implementation is complete. There will be more details to come along with documentation for this feature in the coming weeks.
The new user email that is sent to all new users had a typo in the link's URL. That is now fixed.
Attempts to use the Processor Token on a processor that does not accept that token will now see an error response. This was causing quiet failures later in the processing of TPS transactions instead of an immediate error response.
Our system was not properly handling SEPA returns from Stripe. This is now resolved.
Application Updates allow underwriters to request incremental changes to a merchant's account information. When a merchant submits updated information through their application, underwriters can review, accept, or reject these changes before they take effect.
You can read more about the feature here - https://docs.dhango.com/en/articles/13591821-application-updates
Groups let you organize related accounts and manage shared access in one place. Instead of granting permissions account by account, you can add accounts and users to a group and control what each user can do across all accounts in that group.
You can read more about it here - https://docs.dhango.com/en/articles/14588767-account-groups
ACH transactions against the Fake processor with an account number in 1801 generate a return with return code R01. These returns generate a separate transaction which are included in a batch. This is a different flow to those with an account number ending in 0801 which simulate a return that occurs prior to the batch process. This second scenario updates the original payment transaction with a return date without creating a new return transaction.
We addressed issues with dhango batches including ACH returns and chargebacks that align to the Stripe payouts. These issues are now resolved.
A duplicate detection flag has been added to the platform settings page. This functionality has been on by default and this provides the platform with the option to turn off this feature.
There is already a flag on the POST /transactions/pay endpoint that enables the caller to turn on payer receipts for that individual transaction. We have now added an option at the account level (see the account Overview tab). The account level setting will be used if the flag is left as null on the API call. Otherwise, the value on the API call will prevail.
Transaction details are now shown on the transaction hold page to cut down on flipping back and forth between tabs for context.
dhango will reattempt failed webhook events two extra times. The first reattempt will be after a 1 minute delay. The second reattempt (3rd attempt overall) will trigger after a 5 minute delay.
All attempts will be listed in the events section of the dashboard.
Customer Initiated Entry (CIE) payments are supported through FNBO, allowing merchants to accept payments made via the payer’s bank online bill-pay service.
You can read more at https://dhango.com/features/customer-initiated-entries
We are sanitizing the L2/3 data before it reaches Adyen, removing unsupported characters and extra spacing so it conforms to Adyen's standards.
The shopper interaction has been changed to eCommerce to improve authorization rates.
The view application page now shows the list of accounts that were created from the application. This list is keyword searchable which will come in handy in cases where dozens of accounts are created from a single application.
To ensure support for 3ds while also maintaining the ability to process offline transactions (e.g. on schedule payments without the customer's interaction), we are making use of the "off_session" flag.
The application <> account relationship has now changed so a single application can be used any number of times to generate new accounts. This means a merchant only needs to sign up once even if their application will result in the creation of 5 accounts, for example. There will also be changes to the user experience to provide visibility on which accounts have been created from a single application.
The Account Pricing report has been added to PowerBI. This provides a view of the pricing template and custom pricing settings across the entire portfolio of accounts.
The card brand has also been added as a filter to the processing volume report.
Some card transactions were failing in the sandbox environment after the latest release to use the 2025-04-30.preview version of the Stripe API. This is caused by passing in a 0 value for the discount amount on the line items. The previous version of the Stripe API allowed for a 0 value while the newer version does not. We have added a simple check to ensure we are only passing a discount amount to Stripe if the value is greater than 0.
We are now using Stripe's 2025-04-30.preview version which includes the "Payment Line Items" models for Level 2/3 data. This was done at the request of Stripe which is sunsetting the previous Level 2/3 models on 10/18/2025. There are no changes required by the platform to adopt this version since all done on the dhango side of the integration by remapping data to the new Stripe models.
A bug was introduced in a previous release that caused downgrades on Stripe card transactions. While the efficiencies improved performance, that change inadvertently dropped the postal code from the requests. This was reported, fixed, tested, and deployed the same day to avoid further downgrades.
We have added additional support for Adyen fee reconciliation to bring in non-transactional fees and periodic Adyen billing adjustments to ensure our backend net revenue reporting is as accurate as possible.
We switched to using automatic_async at the suggestion of the Stripe team to cut response time down on the POST /transactions/pay endpoint when paying by credit card. This change may save 100-200ms per call in the sandbox environment (update to be posted once we have production numbers).
We applied a fix to better handle Adyen error messages and translate them so the user sees a specific message instead of a generic error message on failed transactions.
Payer receipts can now be enabled by simply setting the sendPayerReceipt flag to true when executing the initial payment or capture transaction. This will trigger the merchant branded e-receipt to the payer for the initial payment as well as any related refunds, voids, or bank returns.
Check estimates have been added to the sign up process for any US-based merchants alongside monthly ACH volume and count estimates.
Context has been added to the file upload sections of the sign up form to prompt the applicant for file uploads. This is intended to encourage them to supply more documentation during the application process.
The pricing page has been redesigned for better readability. This page has gotten longer as more payment methods have been added so we have added the expand/collapse capability per payment method.
Our tokenization infrastructure has been upgraded for better reliability.
The dashboard account search now supports searching by account key and platform identifier, in addition to the existing criteria.
You now have the option to use the pre-built form and still have the full billing address saved with the token. This saves you from having to collect the billing address each time at the moment of payment. Simply set the collectBillingAddress flag to true and the form will automatically display for you.
This flag is set to false by default to avoid any breaking changes. You will also have to add styling for the new fields so they align to your current design standards.
Canadian merchants were unable to proceed past the financial information step of the sign-up form, preventing completion of the registration process. This issue has been resolved.
We were experiencing an issue that was breaking 3DS in the sandbox environment. This has now been resolved.
Fake transactions are now batched in the sandbox environment. This occurs at 22 GMT on a daily basis.
The TransactionEvent webhook will be triggered for every transaction marking the transaction with a settle date to specify the funds are ready to be pushed out. This normally happens 1-2 business days after the transaction.
The BatchAdd webhook event fires when the transactions are added to a batch followed by a BatchUpdate when the funds are "Sent" to the merchant. This also happens 1-2 business days after the transaction, however, the test environment compresses this timeline to make it easier for developers.
Non profit onboarding wasn't working in Stripe in certain countries like Canada and Australia due to a bug in how the "Structure" was set during company creation. This is now fixed.
The enum for scanned checks has been changed from Scanned to Scan for better consistency in the naming process.