Skip to content

Installing the Payment-extension

This article provides a quick guide to start depending on the Payment extension in your application.

Pre-requisites

  • .NET 6, 7 or 8
  • .AddHttpClient() has been added to the service collection

NuGet

Payment is available as a set of NuGet packages, so you need to add them to the *.csproj file by adding new PackageReference tags as below.

1
2
3
4
<ItemGroup>
  <PackageReference Include="Bizzkit.Blueprint.Extensions.Payment" Version="1.0.0" />
  <PackageReference Include="Bizzkit.Blueprint.Extensions.Payment.<PROVIDER>" Version="1.0.0" />
</ItemGroup>

<PROVIDER> should be replaced with the payment provider you wish to enable support for. You can of course add support for multiple providers if needed.

Configuring settings

Some payment provider integrations use HttpClient and are registered as named HttpClients based on their given payment identifier. You can configure it via your service collection as below.

1
2
3
4
5
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpClient("<PAYMENT_IDENTIFIER>", httpClient =>
{
    httpClient.Timeout = TimeSpan.FromSeconds(60);
});

Registering services

The Bizzkit.Blueprint.Extensions.Payment package adds an extension method to register a PaymentExtensionsBuilder which can then be extended with calls to the individual payment provider packages. This will register all the required implementations, as well as logging to the service collection. See below for an example:

1
2
3
4
builder.Services
    .AddPayment<MyPaymentStorageService, MyPaymentUrlResolver, 
      MyPostPaymentChangeService, MyContext>()
    .AddBambora<MyPaymentOptionContextResolver, MyContext>()

As a client of the library, you must provide implementations of the following interfaces from the base package:

  • IPaymentStorageService
  • IPaymentUrlResolver
  • IPostPaymentChangeService

Furthermore, you must define a record class that extends from PaymentContext, which you can use to pass contextual information (such as a segmentation ID) to the library when it has to call your implementations. This can be useful when deciding if a payment option is enabled or not, resolving URLs, etc.

Each payment provider expects the following interface to be implemented:

  • I<PROVIDER>PaymentOptionContextResolver, e.g. IBamboraPaymentOptionContextResolver

The same payment provider can be added multiple times, however, each invocation must implement a unique I<PROVIDER>PaymentOptionContextResolver. Examples, where this is useful, could be: (1) you have different configurations for individual countries, (2) you have different configurations for B2C and B2B, (3) the given payment provider requires different configurations for some payment schemes, etc.

Logging

The payment library delegates the logging implementation to the Microsoft.Extensions.Logging-package, so the only required method to call is the AddPayment method.

Next step

With the initial configuration done, the next step is to set up a checkout and payment flow supported by the library, which you can read more about here.