Integration · Platform Capability

Enterprise Payment SDKs & Client Libraries

A payment SDK wraps DigiPay.Guru's merchant acquiring APIs in language-specific client libraries, so your engineering team writes less integration plumbing and more product. Standardized authentication, consistent error handling, and sandbox-first testing come built in.

Start Building Request API Access

Technology Matrix — Preview

JavaEnterprise backend integration

Available

Node.jsAPI & web applications

Available

JS / TSWeb client integration

Client Library

.NETEnterprise applications

Roadmap

PythonBackend & automation

Roadmap

Android / iOSMobile payment applications

Roadmap

Build Payment Integrations Faster

A payment SDK exists to remove repetitive, error-prone work from integration: request construction, authentication headers, retries, and response parsing. Instead of writing that layer once per project, engineering teams build against a consistent client library and spend their time on product logic.

Reduced development effort. A payment API SDK provides pre-built methods for common operations — initiating a payment, checking status, retrieving settlement data — so developers call a function instead of assembling a raw HTTP request by hand.

Standardized API interaction. Every call goes through the same client library, which means request formatting, authentication, and response handling stay consistent across a codebase, even as different engineers contribute to it.

Faster implementation. With authentication and error handling abstracted, the first working integration typically takes less time to reach than a direct, from-scratch API integration.

Consistent error handling. A merchant payment SDK can classify errors — validation, authentication, network, retryable — the same way every time, instead of leaving each developer to interpret raw HTTP status codes independently.

Simplified authentication. Credential handling and request signing are handled inside the library, reducing the chance of a credential being mishandled in application code.

Easier testing. SDKs are built to work against the sandbox environment out of the box, so integration testing doesn't require separately reverse-engineering sandbox request formats.

Why Use Payment SDKs?

Integrating directly against a REST API means your team owns request construction, authentication, retries, and error interpretation. A payment gateway SDK takes on that layer, so the API itself becomes an implementation detail rather than something every developer has to relearn.

Reduce Integration Complexity

Common operations are exposed as library methods, reducing how much of the raw API surface a developer needs to understand up front.

Accelerate Development

Pre-built request handling shortens the distance between "start integration" and "first successful call."

Standardize API Interactions

All calls flow through the same client library, keeping integration patterns consistent across teams and projects.

Simplify Error Handling

Errors are classified and surfaced consistently, instead of requiring custom handling for every endpoint.

Improve Developer Productivity

Less time spent on integration plumbing means more time spent on the payment experience itself.

Support Consistent Implementations

New engineers joining a project inherit the same patterns as the rest of the codebase, rather than a bespoke integration approach.

Reference

Direct API Integration vs. SDK-Based Integration

Aspect	Basic User Logs	DigiPay.Guru Audit Trails
Request construction	Built and maintained manually	Handled by client library methods
Authentication handling	Implemented per project	Abstracted inside the SDK
Error handling	Interpreted per developer, per endpoint	Classified consistently by the library
Onboarding new engineers	Relies on internal documentation	Follows documented SDK patterns
Maintenance over time	Custom code ages with the API	Updates ship with SDK releases

SDKs Across Your Technology Stack

Payment SDK and client library support spans backend, web, and mobile development environments. Some environments are available today; others are on the roadmap. Confirm current status with solution engineering before scoping an implementation.

Environment	SDK / Library	Typical Use Case	Status
Java	Java SDK	Enterprise backend integration	Available
Node.js	Node.js SDK	API & web applications	Available
JavaScript / TypeScript	Client Library	Web application front ends	Available
.NET	.NET SDK	Enterprise applications	Roadmap
PHP	PHP SDK	E-commerce applications	Roadmap
Python	Python SDK	Backend & automation	Roadmap
Android	Android SDK	Mobile payment applications	Roadmap
iOS	iOS SDK	Mobile payment applications	Roadmap

A note on availability: This matrix reflects the current SDK roadmap. "Available" environments have a supported client library today; "Roadmap" environments are planned but not yet released. Because SDK availability changes as the roadmap progresses, confirm the current status for your environment with solution engineering or the Developer Portal before committing to a timeline.

Merchant Payment APIs Through SDKs

A merchant acquiring SDK exposes the same core capabilities as the underlying API, packaged as methods your application can call directly.

Merchant Management

Create, update, and retrieve merchant records through library methods instead of raw endpoint calls.

Merchant Onboarding

Drive onboarding steps programmatically as part of a broader application workflow.

Payment Initiation

Initiate a payment transaction with a single method call, with request formatting handled by the SDK.

Payment Status

Check the current status of a transaction without manually constructing a status-check request.

Refunds

Issue refunds against a completed transaction through a consistent, documented method.

Transaction History

Retrieve historical transaction data for reconciliation or customer-facing reporting.

Settlement Information

Pull settlement batch and status data into internal finance or reporting systems.

Reporting

Access operational and financial reporting data programmatically rather than through manual export.

Simplified Authentication

Authentication is one of the most error-prone parts of a direct API integration. A payment SDK handles it inside the library, so application code never has to construct authentication logic by hand.

API Credentials

Credentials are issued per application or environment and referenced by the SDK rather than embedded throughout application code.

Authentication Tokens

Token handling is managed inside the library, reducing the surface area where token logic can go wrong.

Secure Credential Handling

The SDK is designed to keep credentials out of logs and out of places they shouldn't end up.

Request Signing

Where request signing is required, the SDK applies it consistently rather than leaving it to each developer to implement.

Permission Management

Scoped credentials mean an SDK instance can only reach the APIs and data it has been granted access to.

Consistent Error Handling

Client libraries classify errors the same way across every call, so applications can respond predictably instead of parsing raw HTTP responses case by case.

Validation Errors

Malformed or missing request data is surfaced clearly before a request reaches the API.

Authentication Errors

Invalid or expired credentials are classified distinctly from other failure types.

API Errors

Errors returned by the platform are mapped to consistent, structured error objects.

Timeouts

Requests that exceed expected response times are handled predictably rather than hanging indefinitely.

Network Failures

Connectivity issues are distinguished from application-level errors, simplifying troubleshooting.

Retryable Errors

Errors that are safe to retry are identified separately from those that require developer intervention.

Reference

Error Handling Flow — How the SDK Classifies Errors

Application API Call

SDK Error Classifier

Validation Error

Bad request / missing fields

Auth Error

Invalid / expired credentials

Network Error

Timeout / connectivity

API Error

Platform error response

Retryable Error

Safe to retry automatically

// Structured error object
error.type = "ValidationError"
error.code = "INVALID_AMOUNT"
error.retryable = false

Application Error Handler

Responds predictably — every time

Testing & Development

SDKs are built to work against the same sandbox environment available through the Developer Portal, so testing an SDK-based integration follows the same path as testing a direct API integration.

SDK Sandbox

Initialise SDK with sandbox credentials

// Java SDK — sandbox
DigiPayClient client =
  DigiPayClient.builder()
    .apiKey("sk_test_…")
    .sandbox(true).build();

STATUS

Sandbox

REQUESTS

1,204

ERRORS

SDK sandbox — safe to test end to end

Sandbox Environment

A dedicated environment for testing SDK-based integrations without touching production data.

Test Credentials

Separate credentials for sandbox use, kept distinct from production credentials.

Test Transactions

Simulated transactions for validating integration logic end to end.

API Explorer

Explore the underlying API structure that the SDK wraps, for teams that want to see both layers.

Postman Collections

Reference collections for exploring API behavior alongside SDK development.

Integration Testing

Support for structured testing of SDK-based flows before a production release.

SDK Version Management

Enterprise engineering teams need predictability from a dependency they don't control directly. SDK releases are managed with that in mind.

Semantic Versioning

Version numbers reflect the nature of a change, helping teams assess impact before upgrading.

Backward Compatibility

Non-breaking changes are prioritized within a major version so existing integrations keep working.

Release Management

Releases follow a structured process, with changes documented for each version.

Deprecation Notices

Deprecated functionality is flagged ahead of removal, giving teams time to migrate.

Migration Guides

Guidance is provided for moving between major versions with minimal disruption.

Version Support Policy

Current support timelines for SDK versions are maintained in the SDK reference documentation.

Secure Payment Integration

An SDK sits inside your application's trust boundary, so it's designed with the same security discipline expected of any component handling payment data.

Secure API Communication

SDK requests to the platform are made over secure, encrypted connections.

Credential Protection

Credentials are handled inside the library in ways designed to reduce accidental exposure.

Sensitive Data Handling

The SDK is built to minimize how much sensitive payment data application code needs to touch directly.

Tokenization Integration

Where tokenization is used, the SDK is designed to work with tokenized data rather than raw sensitive values.

Auditability

SDK-driven requests flow through the same platform audit trail as any other API call.

Environment Separation

Sandbox and production credentials and configurations are kept clearly separate.

Enterprise Integration Architecture

A payment SDK sits between your application and the underlying merchant acquiring platform, translating library calls into governed API requests.

Enterprise Application

Your application code

DigiPay.Guru SDK

Client library layer

Payment APIs

REST API layer

Merchant Acquiring Platform

Processing · Settlement · Reporting

Supported Integration Models

SDKs are one of several ways to integrate with DigiPay.Guru; the right model depends on your architecture and team.

Direct API Integration

Integrate directly against the REST API for teams that prefer full control over the request layer.

SDK-Based Integration

Use a language-specific client library to reduce integration effort for supported environments.

Hosted Payment Integration

Redirect to a hosted payment experience for teams that want to minimize what touches their own systems.

Embedded Payment Integration

Embed payment components directly into your application's own interface.

Enterprise System Integration

Connect payment capabilities into core banking, ERP, or CRM systems as part of a broader architecture.

Developer Experience

SDKs and client libraries are part of the same developer experience available through the Developer Portal — the two are designed to be used together.

Clear Documentation

SDK reference material organized alongside the broader API documentation set.

Code Examples

Illustrative examples showing common SDK usage patterns.

API References

Underlying API detail available for teams that want to see what the SDK is wrapping.

SDK References

Method-level reference documentation for each supported client library.

Sandbox Testing

The same sandbox environment used for direct API testing supports SDK-based testing.

Integration Guides

Step-by-step guidance for common SDK integration scenarios.

Technical Support

Solution engineering support available for enterprise implementation questions.

Business Benefits

Reduce Development Time

Pre-built request handling shortens the path from integration start to first working call.

Accelerate Payment Product Launches

Faster integration means less time between concept and a shippable payment feature.

Reduce Integration Complexity

Developers work against library methods instead of raw endpoint and authentication logic.

Improve Developer Productivity

Less time spent on integration plumbing, more time spent on product logic.

Standardize Payment Integrations

Every team building on the same SDK follows the same integration patterns.

Simplify Long-Term Maintenance

SDK updates absorb API-level changes, reducing the maintenance burden on application code.

Example Use Cases

Fintech Payment Application

Add merchant payment capability to a fintech product without building the integration layer from scratch.

Merchant Management Platform

Use SDK methods to manage merchant records as part of a broader operations platform.

E-Commerce Application

Integrate payment initiation and status checks into an existing checkout flow.

Banking Application

Extend merchant acquiring capability into an existing banking application.

Enterprise ERP Integration

Pull settlement and transaction data into ERP systems through consistent SDK calls.

Mobile Payment Application

Build mobile payment experiences on supported mobile development environments.

Payment Processor Integration

Connect internal processor systems to DigiPay.Guru through a consistent client library.

Why DigiPay.Guru SDKs & Client Libraries

API-First Architecture

SDKs are built on top of the same APIs that power the platform itself, not a separate simplified layer.

Modular Payment Capabilities

Integrate merchant management, processing, settlement, or reporting independently as needed.

Enterprise Integration

Designed to fit into existing core banking, ERP, and CRM architectures rather than replace them.

Developer Experience

SDKs, documentation, and sandbox testing are designed to work together, not as separate disconnected tools.

Start Building Request API Access

Frequently asked questions

A payment SDK is a software development kit that packages reusable code, authentication handling, and request/response logic so engineering teams can integrate payment APIs without building that plumbing from scratch.

An API is the underlying interface that exposes payment functionality over HTTP. An SDK is a language-specific library that wraps that API, handling authentication, request formatting, and error handling in idiomatic code for a given environment.

Supported and planned development environments are listed in the technology matrix on this page. Availability varies by environment and release stage, so confirm current status with solution engineering before planning an integration.

Yes. A sandbox environment with test credentials and test transactions is available for validating SDK-based integrations before moving to production.

Yes. Code examples and integration guides are available through the Developer Portal and SDK reference documentation.

SDKs follow a structured release process with documented changes between versions. Specific versioning policy details are available in the SDK reference documentation.

Mobile development environments, including Android and iOS, are addressed on the technology matrix on this page as available or roadmap capabilities. Confirm current availability with solution engineering.

Yes. SDKs are designed to integrate into existing applications and platforms rather than requiring a ground-up rebuild.

SDKs are designed to support secure API communication, credential protection, and environment separation between sandbox and production. Full security detail is available in the technical documentation.

SDK reference documentation, code examples, and integration guides are available through the Developer Portal.

Ready to Start Building?

Explore SDKs and client libraries for your technology stack, request API access, and start testing in the sandbox environment.

Start Building Request API Access

Look through your eyes of insight to our insightful thoughts

DigiPay.Guru is born to simplify financial transactions. We love discussing the latest finTech solutions. We write regular blogs where we cover insightful topics with our insightful thoughts to cater you with imperative informations.