Plexo SDK

Independent TypeScript SDK for backend Plexo integrations. OpenAPI contracts, domain resources and a transport that never automatically replays financial writes.

Client: Personal project · Backend
Year: 2026
Role: Architecture, development and testing
Technology: TypeScript, Node.js, Vitest

Plexo SDK cover, independent beta: backend, TypeScript client and payments API.

A Plexo client for the backend

I built this SDK to bring Plexo REST API operations into one client. The work includes types generated from a versioned OpenAPI contract, domain resources and a shared HTTP transport. The integrating application retains control of orders, user authorization and each operation's state.

SDK architecture: the backend uses typed resources through the client and HTTP transport to Plexo; credentials stay on the server. — Simplified SDK architecture. These diagrams explain the code's design; they are not checkout screenshots or evidence of real transactions.

Separating the contract from transport

Types are generated from the OpenAPI snapshot. On top of them, the client exposes resources for payments, customers, sessions, tokenization and payment links. Authentication, timeouts and errors are handled by the transport rather than repeated in every resource. The core package adds no runtime dependencies.

TypeScript
Node.js
Vitest

A timeout does not confirm that a payment failed

A write can reach the provider even if the connection closes before its response arrives. The SDK distinguishes that unknown outcome from a definitive error and does not automatically replay financial writes. Aborting the request is not the same as cancelling a payment.

The integration must retain a durable reference, query authoritative state, and resolve or escalate the operation before deciding on another attempt. Automatic transport retries are limited to operations classified as safe; that policy does not replace application-level reconciliation.

Flow for a payment without a response: the SDK reports an unknown outcome without replaying the charge; the application looks up state and reconciles. — Unknown-outcome scenario. Lookup and reconciliation belong to the application; the SDK does not resend the charge on its own.

Credentials stay out of the browser

The client builds HTTP Basic authentication from server credentials and prevents Authorization and other sensitive headers from being overridden. Environments are explicit, and URLs require HTTPS apart from controlled local exceptions. Error details are bounded and redacted before they are exposed to the integration.

Tests and validation scope

The repository includes contract, resource and transport tests covering authentication, parameter validation, cancellation, timeouts, errors and retry policy. The documentation separates simulated HTTP scenarios from checks performed in the testing environment.

Documented remote validation includes authenticated reads and disposable-customer lifecycle checks in testing. It does not establish an approved financial lifecycle or production business operations. The project is therefore presented as in development, without processed-payment metrics or a production-readiness claim.

Result

Less repeated plumbing; explicit payment decisions

The SDK centralizes the contract and transport without hiding decisions that belong to the business. User authorization, durable persistence, reconciliation and webhook verification remain the responsibility of the integrating application.

Independent personal project, version 0.1.0 in private beta. This is not an official SDK and is not endorsed by Plexo. Using it does not certify PCI compliance. The repository and package are not offered as public downloads; the visuals in this case are technical diagrams based on the reviewed code.