A .NET payment SDK built to solve a real-world integration challenge.

ElavonPaymentsNet

When a project required a capable .NET integration with the Elavon / Opayo Payments PI REST API, I couldn't find an existing SDK that met the requirements. Rather than build and maintain a bespoke collection of HTTP calls within the application, I developed ElavonPaymentsNet: a reusable, strongly typed .NET SDK designed to make payment integration cleaner, safer and easier to maintain.

The result is an open-source SDK that brings a consistent client interface to a complex payment API, backed by automated tests, explicit contract documentation and a dedicated sandbox playground.

A real requirement. No suitable SDK.

The project I was working on needed payment capabilities through the Elavon / Opayo PI REST API. At the time, I couldn't find an existing .NET SDK that provided the level of coverage and integration experience the project required.

That left a choice: implement the integration directly within the application, or build a dedicated library that would provide a more consistent and maintainable approach.

I chose the latter.

Payment integrations involve more than sending a request and reading a response. Authentication, request and response models, error handling, transaction lifecycles and additional requirements such as 3D Secure all need to work together reliably.

Building a dedicated SDK gave me control over those concerns while creating something reusable beyond the original project.

From project requirement to reusable engineering

Rather than exposing raw HTTP calls and JSON payloads to consuming applications, I designed ElavonPaymentsNet around a single client entry point, strongly typed models and focused service groups.

The intention was to make the integration straightforward to use without hiding the important behaviour of the underlying payment API.

Key engineering decisions included:

The result is an abstraction over the API, not an attempt to abstract away the realities of payment processing.

A clear boundary between application code and payment infrastructure

The public interface is intentionally shallow. Applications work through the client and its service groups, while the internal HTTP layer manages communication with the gateway.

This separation keeps authentication, serialisation and transport concerns out of individual service implementations. It also provides a consistent place to handle API errors and apply resilience rules.

The SDK targets .NET 10 and uses HttpClient, IHttpClientFactory and dependency injection conventions familiar to modern .NET applications.

Supporting the payment lifecycle

The SDK covers the key operations exposed by the Opayo PI API, including:

• Standard payments and authorisation flows

• Deferred payments and subsequent capture

• Full and partial refunds

• 3D Secure and Strong Customer Authentication flows

• Tokenisation and reusable card identifiers

• Wallet and Apple Pay-related operations

• Payment instructions and post-payment operations

Typed request and response models provide a consistent interface across these capabilities, while keeping the underlying API behaviour explicit.

Resilience requires payment-aware decisions

In payment systems, retrying a request is not always the right response to a failure. A network interruption can leave the caller uncertain whether a transaction was processed, and blindly resending a payment request can introduce duplicate financial side effects.

ElavonPaymentsNet therefore applies a deliberately conservative retry policy. Transient GET requests can be retried with exponential backoff and jitter; POST operations are not automatically retried.

The SDK also translates HTTP and transport failures into typed exceptions, giving consuming applications a clearer basis for handling errors and investigating uncertain outcomes.

This is a deliberate engineering trade-off: resilience should improve reliability without creating additional risk.

Making complex integration flows easier to work with

Payment APIs often involve several connected operations rather than a single request. The SDK brings these into a consistent .NET interface, including merchant session key and card identifier flows, transaction submission and 3D Secure handling.

For 3D Secure, explicit models and flow handling help the consuming application work with authentication outcomes without having to build every piece of the API interaction from scratch.

Designed to be verified, not just compiled

The SDK includes automated tests covering request mapping, service behaviour, error handling, retry rules, serialisation and other important edge cases. Deterministic HTTP fakes allow these behaviours to be tested without depending on a live gateway.

At the v1.0.2 coverage snapshot, the project recorded:

• 96.81% line coverage

• 95.32% branch coverage

• 98.53% line coverage for the central ElavonApiClient

Separate integration tests exercise the API against the Elavon / Opayo sandbox. These are run explicitly rather than as part of the default unit-test command.

Exercising real payment scenarios

Alongside the library, I built a standalone console playground that references the SDK and exercises payment operations against the sandbox.

It provides a practical way to explore the client interface and validate end-to-end scenarios, including payments, deferred capture, refunds, voids, reusable card identifiers and 3D Secure flows.

The playground also serves as a working reference for developers integrating the SDK into their own applications.

A reusable solution born from a real project need

What began as a requirement for a project became a standalone, open-source .NET SDK.

ElavonPaymentsNet brings the integration behind a consistent client interface, separates application concerns from HTTP infrastructure, and provides a foundation for automated testing and sandbox validation. It also documents the SDK surface explicitly, making the library easier to understand and evolve.

The wider value is in the engineering approach: identify a genuine gap, build the capability needed to solve it, and turn that work into a reusable component rather than leaving it as one-off integration code.