In 2018 we released Commerce ifthenpay, the module that brought Multibanco references to Drupal Commerce. Seven years later, we are publishing version 3.0.0: the module's biggest evolution since then, with dynamic Multibanco references generated by the ifthenpay API, MB WAY payment retries and full support for Drupal 10 and 11.

The silent problem of locally generated references

A Multibanco reference has 9 digits, and the classic local generation algorithm reserves only 4 of them for the order number. It works perfectly up to order 9999. Beyond that, the number has to be compressed to fit, and this is where mathematics turns against the store.

Version 2.x mitigated the problem by spreading order numbers across 9000 possible combinations. It sounds like a lot, but the birthday paradox is relentless: around 112 simultaneously open references are enough for a 50% chance that two different orders share exactly the same reference. In a busy store, that means payments that can be matched to the wrong order, or never reconciled at all. Worst of all, the problem is invisible: everything seems to work, until the day a customer pays and their order stays "unpaid".

The solution: references generated by ifthenpay

Version 3.0.0 introduces a new mode on the Multibanco gateway: instead of computing the reference locally, the module requests it from the ifthenpay REST API, using the account's MB Key. The differences are structural:

• The order number is sent in full (up to 25 characters): no truncation, no compression, no collisions;
• Each transaction receives a unique identifier, and the payment confirmation is validated against it;
• References can have an expiry date (from 1 day to 2 years), something impossible in local mode;
• There is a sandbox environment to validate the integration without real transactions.

The local mode remains available for backwards compatibility, and open references generated the old way keep reconciling after the switch: stores migrate with no downtime window.

MB WAY: promise delivered, and then some

When we wrote about version 2.x, MB WAY was "future development". Version 3.0.0 closes the loop: besides push payments at checkout, customers can re-send the payment request from their order history without going through checkout again, and the store team can trigger a push directly from the backoffice. Fewer orders abandoned because a push expired on someone's phone.

Ready for Drupal's future

Version 3.0.0 supports Drupal 10 and Drupal 11, and Commerce 2.x and 3.x. The module now runs continuous integration on drupal.org, with more than 50 automated tests validating every change on both Drupal versions, and stable releases are covered by the community's security advisory policy.

If your store runs version 2.x, we recommend upgrading: the 2.x branch is no longer supported and does not include the protections against reference collisions.

composer require 'drupal/commerce_ifthenpay:^3.0' Need help with payments in Drupal Commerce?

Bloomidea develops and maintains Commerce ifthenpay and has been building Drupal Commerce stores for the Portuguese market for more than a decade: Multibanco, MB WAY, cards, Stripe and PayPal, with ERP and logistics integrations. Talk to us about your project.

The debate over open-source infrastructure often ends at agreement. Matthew Saunders wants it to continue into budgets, governance, and contributor support.

Your Drupal site is on a current version, gets security updates, and technically works - yet editing is painful and every small change waits in a developer queue. The platform is rarely the problem.

Fourteen common implementation mistakes that make a Drupal site feel broken - with symptoms, diagnosis, and fixes for each. Most cost a fraction of a rebuild to put right.

Take Away At Tag1, we believe in proving AI within our own work before recommending it to clients. This post is part of our AI Applied content series, where team members share real stories of how they're using Artificial Intelligence and the insights and lessons they learn along the way. Here, Lucas Hedding, Senior Backend Engineer & Migration Lead and Drupal core subsystem maintainer for authentication/authorization, used Claude to work through over 1,200 open issues in the Drupal auth/authZ issue queues and co-architect a new pluggable authentication system for Drupal core, without writing a single line of code.

When approaching AI, I've done so warily. Maybe it was because I was a skeptic, but my first endeavors were not glowing success stories. My first real attempt to kick the tires ended with me kicking AI to the curb and doing some regex and search/replace to finish what it started. I chalk it up to a mix of model maturity and, let's be honest, my own ill-directed uses.

But more recently I've been finding wins. I find AI very useful for writing test cases for test-driven development (TDD). It's also really good at troubleshooting. It takes a bug report, follows the code paths, and writes a failing test that reproduces the bug. When you solve the problem, you can be sure you have solved it. And more importantly, that it was even a problem in the first place.

Putting AI to Work on a Real Problem

It was at this point, I realized that AI might be able to help me with my Drupal Core maintainer duties. For those that don’t know, I maintain an insane number of contrib modules and am a core subsystem maintainer in 3 areas, namely migrate, image, and authentication/authorization. The last area of auth/authZ is in desperate need of modernization.

The planning issue requirements and roadmap are all open. The community design review hasn't started yet, so now is a good time to take a look: [Plan] YAML-Based Pluggable Authentication Flow

The first part of the problem for auth/authZ is that there aren't any core components in the core issue queue for the sub system. I have to look in a few module queues and the base system to find relevant issues. I filed this issue to establish a dedicated auth/authZ component in the Drupal core queue.

To help me get my mind around the space, I had AI query all 1,200 issues in the module-based issue queues. Then it spun out from there to find referenced issues. I leveraged a local file cache of d.o issues so I didn’t have to hit the drupal.org API repeatedly as I was tweaking the discovery.

This demonstrates the first lesson I’ve learned with AI. It is really good at doing directed research and planning. But you need to give it guard rails. I had to tell it to add a cache. I had to tweak the issue filters. I had to think about what I wanted. AI wouldn’t think for me. But at the end, I had several hundred issues downloaded locally.

Making Sense of 1,200 Issues

Then came the next step. I asked AI to create a mind map using mermaid.live. With over 1,000 issues, I didn’t want something that was too unmanageable. I picked a couple issues that seemed key to me and asked AI to give me a mind map with issues directly related to authentication (excluding authorization for the moment). That shrank things down to just a few hundred. But the large picture of categorized issues in a mind map started to tell a story.

The mind map story led me back to the planning phase again. This time I used BMAD, an AI methodology specifically structured to guide planning a task using AI. I fed it the pain points and asked it to look at some reference PHP and non-PHP authentication frameworks. It researched Laravel, Symfony, Drupal and Keycloak. At this point I had enough data to request it to write some pros/cons and possible pseudo implementations.

Somewhere in this whole process DrupalCon Chicago happened. Then a few weeks later MidCamp in Chicago happened. This gave me ready access to real people to bounce ideas off. They asked some really great questions. I fed these questions back into AI and refined the design even further.

Then more recently, I had the opportunity to speak at a Drupal meetup on Zoom. I took all the data I’d gathered, the mind maps, the design artifacts generated by BMAD and created a nice slideshow presentation. But the source data was from research provided by AI. The attendees at the meetup had even more feedback. I fed this feedback back into AI and now have a pretty defensible architecture for a new authentication system in Drupal core — the YAML-Based Pluggable Authentication Flow outlined in the planning issue. Broken down into phases with dependencies identified between phases of work.

The Blank Sheet Problem

We haven’t built the new system. No code has been written. But AI helped architect everything. I don’t think a human could parse that many hundreds of drupal.org issues, create a mind map, and build a new architecture without massive amounts of effort. AI is great at holding lots of nuggets of data in memory all at once. It is optimally designed to help with just such a task as I went through.

Time will tell if the architecture co-developed by AI proves useful. I do know it has helped with the “blank sheet of paper” -syndrome. The feeling where you know you need to do something but don’t know where to start. You just sit there staring at the blank sheet of paper hoping for inspiration. Even if we entirely threw out the new architecture, we have something to start.

For those interested in the artifacts from this discovery, you can visit https://www.drupal.org/project/drupal/issues/3593328.

phpstan-drupal 2.1.0 is out. The theme of this release: rules and behaviors that proved themselves as opt-ins are now the defaults. If you run `composer update` and see new errors, that is the release working as intended — everything below includes the configuration to opt back out.

Nine rules are now enabled by default

These rules shipped as opt-ins over the 2.0 cycle. They have had time to bake, and they catch real bugs, so they no longer require configuration:

Join us THURSDAY, July 16 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone.

Information on joining the meeting can be found in our collaborative Google document.

Boerland links his board candidacy to a question now facing Drupal: how the project can expand institutional support without narrowing the path for contributors, local communities, and site owners.

Getting each audience to the right section is only half the job. The harder part is making the experience feel personal and routing every visitor to the right form without a maze of options.

Part 2 of this Drupal guide covers user journeys, smart Webform contact routing, and pragmatic content personalization for multiple audiences.

Got your Drupal website up and running but haven't figured how to maintain it? Read to find out how you can optimize your site and make it future-ready.

Drupal site security rarely stops at core and module updates. Canonical’s survey shows why package provenance, Linux maintenance, and patch ownership remain part of delivery risk.