Adapter Pattern in Java: How to Integrate Payment Gateways Without Tight Coupling”

Lucas Carlos — Sun, 13 Sep 2026 17:03:31 +0000

Software systems rarely remain isolated.

Even applications that start out simple eventually need to communicate with banks, payment gateways, email services, ERPs, shipping providers, and third-party APIs.

The problem begins when each integration has a different contract and those differences start leaking directly into the application's business logic.

This is exactly the kind of situation where the Adapter Pattern becomes useful.

In this article, we will explore how to apply the Adapter Pattern in Java to a real-world scenario involving multiple payment gateways. We will analyze not only the implementation itself, but also the architectural problem that motivates the pattern, its structure, advantages, limitations, and impact on system evolution.

1. Fundamental Concepts

What Are Design Patterns?

Before discussing Adapter specifically, it is important to understand what a Design Pattern actually is.

A Design Pattern is not ready-made code that should simply be copied into any application.

Instead, it represents a reusable solution to a recurring software design problem.

Throughout the development of different systems, certain architectural problems tend to appear repeatedly.

For example:

How can we create complex objects without tightly coupling the code to concrete classes?
How can incompatible objects work together?
How can behavior be changed at runtime?
How can a class avoid depending directly on several concrete implementations?
How can multiple components be notified when an event occurs?

Design Patterns provide proven ways to organize solutions to these kinds of problems.

The classic patterns documented by the Gang of Four, or GoF, are usually grouped into three main categories.

Creational Patterns

These patterns deal with object creation.

Examples include:

Factory Method;
Abstract Factory;
Builder;
Singleton;
Prototype.

Structural Patterns

These patterns deal with how classes and objects are composed and connected.

Examples include:

Adapter;
Facade;
Decorator;
Composite;
Proxy;
Bridge.

Behavioral Patterns

These patterns focus on communication and responsibility distribution between objects.

Examples include:

Strategy;
Observer;
Command;
State;
Template Method.

The pattern discussed in this article belongs to the second category.

What Is the Adapter Pattern?

The Adapter Pattern is a structural design pattern used when two components have incompatible interfaces but still need to work together.

The Adapter acts as a translation layer.

Instead of modifying the entire system to understand an external component, we create an intermediate object that converts the external interface into the format expected by the application.

The basic idea can be represented like this:

Application
   |
   v
Internal Interface
   |
   v
Adapter
   |
   v
External Component

The application does not need to understand how the external component works internally.

It only needs to understand its own contract.

The Adapter is responsible for translating calls, parameters, and responses.

A Simple Analogy

A common analogy is a power outlet adapter.

Imagine buying a laptop in another country.

The charger works perfectly, and the electrical outlet also works perfectly.

The problem is that their physical formats are incompatible.

There are three possible solutions.

The first would be replacing the entire electrical installation.

The second would be modifying the laptop charger.

The third would be placing an adapter between them.

The third option is usually the simplest.

The same idea can be applied to software:

Application
    |
    v
Adapter
    |
    v
External API

Neither the application nor the external library necessarily needs to be rewritten.

We simply create a layer capable of translating between them.

What Problem Does the Adapter Pattern Solve?

Consider an e-commerce platform.

Initially, the company works with only one payment gateway called LegacyBank.

The code could look something like this:

public class PaymentService {

    private final LegacyBankClient client;

    public PaymentService(LegacyBankClient client) {
        this.client = client;
    }

    public void processPayment(String orderId, double value) {
        client.executeCharge(orderId, value);
    }
}

In a very small system, this may seem completely acceptable.

The problem becomes clearer when we analyze the dependency:

PaymentService
      |
      v
LegacyBankClient

The business logic is directly tied to an external provider.

If LegacyBankClient changes, PaymentService may also need to change.

If the company stops working with LegacyBank, PaymentService will need to be modified.

If a second provider is introduced, the code may start growing quickly.

For example:

if (provider.equals("LEGACY_BANK")) {

    legacyBank.executeCharge(
            orderId,
            amount.doubleValue()
    );

} else if (provider.equals("MODERN_PAY")) {

    modernPay.createPayment(
            customerId,
            amount,
            orderId
    );

}

Then a third gateway is added:

else if (provider.equals("FAST_PAY")) {
    // New integration
}

Then a fourth:

else if (provider.equals("GLOBAL_PAY")) {
    // Another integration
}

At this point, PaymentService starts accumulating responsibilities.

It is no longer responsible only for coordinating payments.

It now also understands:

• external contracts;
• parameter formats;
• authentication details;
• response handling;
• return codes;
• provider-specific naming;
• type conversions;
• implementation details of each vendor.

This significantly increases coupling.

The Coupling Problem

Imagine that our service knows all of this:

PaymentService
    |
    +-- knows how LegacyBank works
    |
    +-- knows how ModernPay works
    |
    +-- knows how FastPay works
    |
    +-- knows how GlobalPay works

This means external changes can directly affect internal business logic. For example, if ModernPay changes its API from:

createPayment(...)

to:

authorizeTransaction(...)

that change could directly affect our business layer.

That is not ideal.

A healthier architecture would look like this:

PaymentService
      |
      v
PaymentGateway

The application defines the contract it wants to use. External implementation details remain outside the business logic.

Participants in the Adapter Pattern

The classic Adapter Pattern includes several important participants.

Client

The Client is the code that wants to use a particular service.

In our case:

PaymentService

The service wants to process payments

Target

The Target is the interface the Client expects to use.

In our project:

PaymentGateway

It represents the internal contract expected by the application.

Adaptee

The Adaptee is the existing class whose interface is incompatible with the system.

In our case:

LegacyBankClient
ModernPayClient

These classes represent external libraries or APIs.

Adapter

The Adapter is responsible for translating between the Target and the Adaptee.

We will have:

LegacyBankAdapter
ModernPayAdapter

The Adapter receives a call in the format used by our domain and converts it to the format expected by the external provider.

The Complete Flow

The overall behavior can be represented like this:

PaymentService
      |
      | calls pay()
      v
PaymentGateway
      |
      v
ModernPayAdapter
      |
      | translates PaymentRequest
      v
ModernPayClient
      |
      | calls the external API
      v
ModernPayResponse
      |
      | translates the response
      v
PaymentResult
      |
      v
PaymentService

Notice that translation happens in both directions.

First:

Internal model -> External model

Then:

External model -> Internal model

This is one of the Adapter's main responsibilities.

2. Development

Real-World Scenario

Imagine an e-commerce platform that processes thousands of orders. During its first few years, all payments were handled by a single provider:

LegacyBank

The initial architecture looked like this:

Customer
   |
   v
Checkout
   |
   v
PaymentService
   |
   v
LegacyBank

As long as there was only one provider, the solution worked. As the company grew, new requirements emerged.

The business started demanding:

• a second payment gateway;
• the ability to compare fees;
• redundancy in case one provider became unavailable;
• support for new payment methods;
• easier provider negotiation;
• the ability to replace a provider in the future.

The company then decided to integrate ModernPay. The problem was that both APIs had completely different contracts.

LegacyBank API

The legacy gateway exposes an operation similar to:

executeCharge(
    String reference,
    double value
)

Its response is:

LegacyBankResponse

containing:

status
transactionCode

ModernPay API

The new provider uses:

createPayment(
    String customerId,
    BigDecimal amount,
    String orderId
)

And returns:

ModernPayResponse

containing:

successful
paymentId

Both APIs serve the same business purpose:

process a payment.

But their contracts are completely different.

The Naive Solution

One possible solution would be to let PaymentService understand every gateway directly.

PaymentService
    |
    +-- LegacyBankClient
    |
    +-- ModernPayClient

However, this creates strong coupling. Every new gateway would require modifications to the same class. In addition, conversion logic would also end up inside it:

PaymentService
    +-- convert PaymentRequest to LegacyBank format
    +-- convert LegacyBank response
    +-- convert PaymentRequest to ModernPay format
    +-- convert ModernPay response
    +-- execute payment business rules

Different responsibilities are clearly being mixed together.

Architecture Using Adapter

The proposed solution creates an internal contract called:

PaymentGateway

Every payment provider used by the application will be exposed through this interface.

The architecture becomes:

Customer
   |
   v
Checkout API
   |
   v
PaymentService
   |
   v
PaymentGateway
   |
   +----------------+
   |                |
   v                v
LegacyBankAdapter  ModernPayAdapter
   |                |
   v                v
LegacyBank API     ModernPay API

The most important point is:

PaymentService does not know the external providers.

It only knows:

PaymentGateway

Visual Representation 1 — UML Class Diagram

The first diagram required by the assignment represents the structure of the classes.

In this diagram, we can clearly identify:

Target -> PaymentGateway

Client -> PaymentService

Adapters -> LegacyBankAdapter and ModernPayAdapter

Adaptees -> LegacyBankClient and ModernPayClient

The UML diagram should not be merely decorative.

It must accurately reflect the code presented in the article.

Visual Representation 2 — Software Architecture

Now we can view the pattern within a broader software ecosystem.

The two diagrams serve different purposes.The UML diagram explains:

• How are the classes organized?

The architecture diagram explains:

• Where does the Adapter fit within the overall system?

That distinction is important because they represent two different perspectives.

Java Implementation

Now let's implement exactly what was shown in the UML diagram.

1. Creating the Internal Contract

First, we define the interface representing any payment gateway accepted by our application.

public interface PaymentGateway {

    PaymentResult pay(PaymentRequest request);

}

This interface has a simple responsibility:

receive a payment request and return its result.

Notice that we are not using any LegacyBank or ModernPay-specific types.

This is intentional.

Our domain should not depend on external provider models.

2. Defining the Payment Request

We can use a record, available in modern versions of Java.

import java.math.BigDecimal;

public record PaymentRequest(
        String orderId,
        BigDecimal amount,
        String customerId
) {
}

Using BigDecimal for monetary values is preferable to floating-point types such as double inside the application's domain.

Our system keeps its preferred internal model.

If a specific external API requires a double, the Adapter is responsible for performing that conversion.

This detail matters.

The domain should not be weakened simply because an external integration uses a particular representation.

3. Standardizing the Result

We also create our own response type:

public record PaymentResult(
        boolean approved,
        String transactionId,
        String message
) {
}

Regardless of which provider is used, the rest of the application always receives a PaymentResult.

This standardizes how responses are consumed.

4. The Legacy Client

Imagine that we have no control over this class.

It could come from a third-party library.

public class LegacyBankClient {

    public LegacyBankResponse executeCharge(
            String reference,
            double value
    ) {

        System.out.println(
                "Processing payment through LegacyBank..."
        );

        return new LegacyBankResponse(
                "OK",
                "LEGACY-" + System.currentTimeMillis()
        );
    }
}

Its response also belongs to the external provider:

public record LegacyBankResponse(
        String status,
        String transactionCode
) {
}

The problem is clear.

Our internal contract provides:

pay(PaymentRequest request)

LegacyBank provides:

executeCharge(
    String reference,
    double value
)

The interfaces are incompatible.

5. Creating LegacyBankAdapter

Now we create the bridge between both contracts.

public class LegacyBankAdapter
        implements PaymentGateway {

    private final LegacyBankClient client;

    public LegacyBankAdapter(
            LegacyBankClient client
    ) {
        this.client = client;
    }

    @Override
    public PaymentResult pay(
            PaymentRequest request
    ) {

        LegacyBankResponse response =
                client.executeCharge(
                        request.orderId(),
                        request.amount().doubleValue()
                );

        boolean approved =
                "OK".equalsIgnoreCase(
                        response.status()
                );

        String message = approved
                ? "Payment approved"
                : "Payment declined";

        return new PaymentResult(
                approved,
                response.transactionCode(),
                message
        );
    }
}

This is the core of the pattern.

Notice the two conversions.

First:

request.orderId()
request.amount().doubleValue()

convert our internal object into the parameters expected by LegacyBank.

Then:

response.status()
response.transactionCode()

are converted into:

PaymentResult

As a result, the rest of the system never needs to know that LegacyBank uses "OK" as a status value.

6. Implementing ModernPay

Now consider another provider.

import java.math.BigDecimal;

public class ModernPayClient {

    public ModernPayResponse createPayment(
            String customerId,
            BigDecimal amount,
            String orderId
    ) {

        System.out.println(
                "Processing payment through ModernPay..."
        );

        return new ModernPayResponse(
                true,
                "MODERN-" + System.currentTimeMillis()
        );
    }
}

Response:

public record ModernPayResponse(
        boolean successful,
        String paymentId
) {
}

The incompatibility still exists.

But now we do not need to modify PaymentService.

We simply create another Adapter.

7. ModernPayAdapter

public class ModernPayAdapter
        implements PaymentGateway {

    private final ModernPayClient client;

    public ModernPayAdapter(
            ModernPayClient client
    ) {
        this.client = client;
    }

    @Override
    public PaymentResult pay(
            PaymentRequest request
    ) {

        ModernPayResponse response =
                client.createPayment(
                        request.customerId(),
                        request.amount(),
                        request.orderId()
                );

        String message =
                response.successful()
                        ? "Payment approved"
                        : "Payment declined";

        return new PaymentResult(
                response.successful(),
                response.paymentId(),
                message
        );
    }
}

Again, provider-specific details remain isolated.

ModernPay works with:

successful
paymentId

Our system works with:

approved
transactionId
message

Who translates between them?

ModernPayAdapter

8. Identifying the Providers

We create an enum:

public enum PaymentProvider {

    LEGACY_BANK,
    MODERN_PAY

}

This avoids directly working with Strings such as:

"LEGACY"

or:

"MODERN"

and reduces the chance of typing errors.

9. Creating PaymentService

Now we can write the main payment service.

import java.util.Map;

public class PaymentService {

    private final Map<
            PaymentProvider,
            PaymentGateway
            > gateways;

    public PaymentService(
            Map<PaymentProvider, PaymentGateway> gateways
    ) {
        this.gateways = gateways;
    }

    public PaymentResult process(
            PaymentProvider provider,
            PaymentRequest request
    ) {

        PaymentGateway gateway =
                gateways.get(provider);

        if (gateway == null) {
            throw new IllegalArgumentException(
                    "Gateway not configured: "
                            + provider
            );
        }

        return gateway.pay(request);
    }
}

This code demonstrates an important architectural change.

The service does not contain:

LegacyBankClient

or:

ModernPayClient

It contains:

PaymentGateway

This means that PaymentService depends on an abstraction.

10. Configuring the Application

Now we create the objects.

import java.math.BigDecimal;
import java.util.Map;

public class Main {

    public static void main(String[] args) {

        PaymentGateway legacyGateway =
                new LegacyBankAdapter(
                        new LegacyBankClient()
                );

        PaymentGateway modernGateway =
                new ModernPayAdapter(
                        new ModernPayClient()
                );

        Map<PaymentProvider, PaymentGateway>
                gateways = Map.of(

                PaymentProvider.LEGACY_BANK,
                legacyGateway,

                PaymentProvider.MODERN_PAY,
                modernGateway
        );

        PaymentService paymentService =
                new PaymentService(gateways);

        PaymentRequest request =
                new PaymentRequest(
                        "ORDER-1001",
                        new BigDecimal("299.90"),
                        "CUSTOMER-500"
                );

        PaymentResult result =
                paymentService.process(
                        PaymentProvider.MODERN_PAY,
                        request
                );

        System.out.println(
                "Payment approved: "
                        + result.approved()
        );

        System.out.println(
                "Transaction: "
                        + result.transactionId()
        );

        System.out.println(
                "Message: "
                        + result.message()
        );
    }
}

What Happens During Execution?

Suppose we select:

PaymentProvider.MODERN_PAY

The execution flow will be:

Main
 |
 v
PaymentService.process()
 |
 v
Map looks up MODERN_PAY
 |
 v
ModernPayAdapter
 |
 v
ModernPayClient
 |
 v
ModernPay API
 |
 v
ModernPayResponse
 |
 v
ModernPayAdapter converts it
 |
 v
PaymentResult
 |
 v
PaymentService

If we select:

PaymentProvider.LEGACY_BANK

the flow only changes after the provider selection:

PaymentService
 |
 v
LegacyBankAdapter
 |
 v
LegacyBankClient

The core business logic remains unchanged.

Adding a Third Gateway

Imagine that the company decides to integrate another provider:

FastPay

Without Adapter, we might need to modify PaymentService.

With the current architecture, we can simply create:

public class FastPayAdapter
        implements PaymentGateway {

    private final FastPayClient client;

    public FastPayAdapter(
            FastPayClient client
    ) {
        this.client = client;
    }

    @Override
    public PaymentResult pay(
            PaymentRequest request
    ) {

        // Conversion for FastPay

        return new PaymentResult(
                true,
                "FAST-123",
                "Payment approved"
        );
    }
}

Then we add:

FAST_PAY

to the enum and configure the implementation.

The internal logic of PaymentService remains almost unchanged.

Relationship With SOLID Principles

Although Adapter is a Design Pattern and SOLID is a separate set of principles, there is an interesting relationship between them.

Dependency Inversion Principle

One of the biggest improvements in this architecture can be seen here:

PaymentService
      |
      v
PaymentGateway

instead of:

PaymentService
      |
      v
ModernPayClient

or:

PaymentService
      |
      v
LegacyBankClient

The business layer now depends on an abstraction.

Single Responsibility Principle

Before:

PaymentService
    +-- payment business logic
    +-- LegacyBank conversion
    +-- ModernPay conversion
    +-- external API handling

After:

PaymentService
    +-- coordinates payment processing

LegacyBankAdapter
    +-- handles LegacyBank integration

ModernPayAdapter
    +-- handles ModernPay integration

Responsibilities are more clearly separated.

Open/Closed Principle

Ideally, we want the system to remain open for extension while avoiding unnecessary modifications to existing code.

Adding another gateway mainly means creating another implementation of:

PaymentGateway

instead of inserting more provider-specific details into the core payment logic.

Testability

Another important benefit is the ability to test PaymentService without calling real payment gateways.

We can create a fake gateway:

public class FakePaymentGateway
        implements PaymentGateway {

    @Override
    public PaymentResult pay(
            PaymentRequest request
    ) {

        return new PaymentResult(
                true,
                "TEST-123",
                "Test payment approved"
        );
    }
}

In a test:

import java.math.BigDecimal;
import java.util.Map;

public class PaymentServiceTest {

    public static void main(String[] args) {

        PaymentGateway fakeGateway =
                new FakePaymentGateway();

        PaymentService service =
                new PaymentService(
                        Map.of(
                                PaymentProvider.MODERN_PAY,
                                fakeGateway
                        )
                );

        PaymentResult result =
                service.process(
                        PaymentProvider.MODERN_PAY,
                        new PaymentRequest(
                                "ORDER-1",
                                new BigDecimal("100.00"),
                                "CUSTOMER-1"
                        )
                );

        assert result.approved();
    }
}

This means our test does not depend on:

internet access;
real APIs;
credentials;
gateway availability;
actual financial transactions.

The abstraction makes automated testing significantly easier.

Before and After

We can summarize the architectural change.

◘ Before

PaymentService
    |
    +-- LegacyBankClient
    |
    +-- ModernPayClient
    |
    +-- LegacyBank conversion
    |
    +-- ModernPay conversion
    |
    +-- provider-specific integration rules

◘ After

PaymentService
      |
      v
PaymentGateway
      |
      +-- LegacyBankAdapter
      |       |
      |       v
      |   LegacyBankClient
      |
      +-- ModernPayAdapter
              |
              v
          ModernPayClient

The total number of classes may increase. However, the responsibilities become clearer and better organized.That leads to an important point.

Design Patterns Do Not Necessarily Reduce the Amount of Code

There is a common misconception that applying a Design Pattern will always result in less code.

That is not necessarily true.

In this example, we could place everything in a single class using a few if statements.

We would probably have fewer files.

But code size is not the only relevant metric.

We also need to consider:

• maintainability;
• readability;
• evolution;
• testability;
• coupling;
• impact of changes;
• separation of responsibilities.

In small projects, creating several adapters may be unnecessary.In systems with multiple integrations and constant evolution, this separation becomes much more valuable.

Advantages of the Adapter Pattern

1. Reduced Coupling

The main business logic no longer depends directly on external APIs. This prevents third-party details from spreading throughout the system.

2. Change Isolation

Imagine that ModernPay changes:

paymentId

to:

transactionReference

Most of the impact can remain restricted to:

ModernPayAdapter

The domain does not necessarily need to change.

3. Legacy System Integration

We do not always have the ability to modify older systems. An Adapter allows us to use a legacy system without changing its original implementation.

4. Easier Provider Replacement

If LegacyBank is no longer used, its Adapter can be removed without rewriting the entire payment flow.

5. Better Testability

Real implementations can be replaced with fakes, mocks, or stubs.

6. Domain Protection

External models do not need to spread across the rest of the application.

Instead of using:

ModernPayResponse

throughout the system, we immediately convert it into:

PaymentResult

Disadvantages and Trade-Offs

Every Design Pattern has a cost.

Using Adapter also introduces additional complexity.

1. More Classes

For each integration, we may end up with:

Client
Adapter
DTOs
Mapper
Configuration

In a small project, this may feel excessive.

2. More Levels of Indirection

◘ Before:

PaymentService
 |
 v
API

◘ After:

PaymentService
 |
 v
PaymentGateway
 |
 v
Adapter
 |
 v
Client
 |
 v
API

The architecture becomes more flexible, but also introduces more layers.

3. Adapters Still Require Maintenance

Adapter does not eliminate external changes.

If ModernPay changes its API, we still need to update code.

The difference is that we try to contain that change within the Adapter.

4. Overly Generic Interfaces Can Become Problematic

Imagine that LegacyBank supports:

refunds
installments
Pix
bank slips
credit cards

while ModernPay supports only:

credit cards

Creating one huge interface that attempts to represent every feature from every provider may create another architectural problem.

The abstraction must represent meaningful concepts within the domain.

5. Adapter Does Not Solve Availability Problems

It is important not to assign responsibilities to the pattern that it does not have.

Adapter does not automatically solve:

• timeouts;
• service outages;
• circuit breaking;
• retries;
• load balancing;
• high availability;
• network failures;
• duplicate requests;
• idempotency.

These concerns require additional architectural mechanisms.

Adapter Is Not Strategy

Adapter and Strategy can appear together, but they solve different problems.

Adapter

The question is:

How can components with different interfaces work together?

Example:

PaymentGateway
       |
       v
ModernPayAdapter

Strategy

The question is:

How can I select between different algorithms or behaviors?

For example:

PaymentStrategy
   +-- CheapestGatewayStrategy
   +-- FastestGatewayStrategy
   +-- FallbackGatewayStrategy

A more advanced architecture could use both.

Strategy could decide:

• Which gateway should be used?

Adapter would handle:

• How do we communicate with the selected gateway?

This distinction matters because Design Patterns are not necessarily competitors.

They can be combined.

Adapter Is Not Facade Either

Facade has a different purpose.Its goal is to provide a simplified interface to a complex subsystem.

Adapter has another primary concern:

• compatibility between interfaces.

An Adapter may simplify an integration as a side effect, but its main intention is to adapt incompatible contracts.

When Should You Use Adapter?

Adapter is particularly useful when:

• an external library does not match the application's expected contract;
• multiple external APIs need to be integrated;
• legacy systems need to be incorporated;
• the domain should be protected from third-party models;
• different providers perform similar functions through different interfaces;
• an existing class cannot be modified directly.

When Might Adapter Be Unnecessary?

Design Patterns should not be applied simply because they exist.

Adapter may be overengineering when:

• there is only one extremely simple integration;
• the external interface already matches the application's needs;
• there is no realistic expectation of evolution;
• the extra layer does not provide meaningful maintainability benefits.

The context should justify the abstraction.

A Broader Architectural View

In a real-world application, Adapter would only be one part of the overall architecture.

We could have:

                    +---------------+
                    |   Front-end   |
                    +-------+-------+
                            |
                            v
                    +---------------+
                    | Checkout API  |
                    +-------+-------+
                            |
                            v
                    +---------------+
                    | Order Service |
                    +-------+-------+
                            |
                            v
                    +---------------+
                    |PaymentService |
                    +-------+-------+
                            |
                            v
                    +---------------+
                    |PaymentGateway |
                    +-------+-------+
                            |
               +------------+-------------+
               |                          |
               v                          v
      +-----------------+       +-----------------+
      |LegacyBankAdapter|       |ModernPayAdapter |
      +--------+--------+       +--------+--------+
               |                          |
               v                          v
      +-----------------+       +-----------------+
      | LegacyBank API  |       | ModernPay API   |
      +-----------------+       +-----------------+

Around these integrations, we could also add:

Retry
Timeout
Circuit Breaker
Logging
Metrics
Tracing
Authentication

This demonstrates an important architectural lesson:

The Adapter solves a specific problem.

It is not the entire architecture.

It is one component within it.

3. Conclusion

In this article, we analyzed the Adapter Pattern in a scenario involving a Java application integrating multiple payment gateways.

The original problem was not simply that two APIs were different.

The real issue was the coupling that could emerge if the business layer started depending directly on each provider's specific contract.

The solution was to introduce an abstraction:

PaymentGateway

and create adapters responsible for translating each external API into that common contract.

We moved from an architecture like this:

PaymentService
   |
   v
Specific providers

to:

PaymentService
   |
   v
PaymentGateway
   |
   v
Adapters
   |
   v
External APIs

The main benefit of the pattern is not reducing the number of lines of code.

Its real value is controlling dependencies.

By isolating external integrations, we can improve important system characteristics such as:

• maintainability;
• testability;
• readability;
• extensibility;
• change isolation;
• separation of responsibilities.

At the same time, there is a cost.

We introduce more classes, more interfaces, and more levels of indirection.

For that reason, just like any other Design Pattern, Adapter should not be applied automatically.

It should be used when the architectural problem genuinely justifies it.

My Perspective on the Pattern

After studying Adapter in more depth, I realized that the implementation itself is not particularly complex. Creating a class that implements an interface and delegates calls to another class is relatively straightforward. The most interesting part is the architectural decsion behind it.

The real value appears when we understand that we are creating a boundary between:

our system

and:

an external system

That boundary prevents external implementation details from spreading throughout the application.It also made it clearer to me that Design Patterns are not mandatory recipes.The most important step is identifying the problem first. Only then should we evaluate whether a particular pattern is the right solution.

In this payment gateway scenario, Adapter makes sense because we have different providers performing essentially the same business function while exposing incompatible contracts.

References

• Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John.
Design Patterns: Elements of Reusable Object-Oriented Software.
Addison-Wesley, 1994.

• Freeman, Eric; Robson, Elisabeth.
Head First Design Patterns.
O'Reilly Media.

• Oracle Java Documentation.

• Refactoring.Guru — Adapter Design Pattern.

What About You?

If you were building a platform that needed to integrate five or six different payment gateways, how would you structure those integrations? Would you use the Adapter Pattern to create a common interface, or would you choose a different approach?

DEV Community: Lucas Carlos

Adapter Pattern in Java: How to Integrate Payment Gateways Without Tight Coupling”

1. Fundamental Concepts

What Are Design Patterns?

Creational Patterns

Structural Patterns

Behavioral Patterns

What Is the Adapter Pattern?

A Simple Analogy

What Problem Does the Adapter Pattern Solve?