From Payments to Open APIs

The first stage of payment digitalisation was making the transaction electronic.

The next stage is harder.

Making everything behind the transaction work together.

A restaurant may receive a digital payment in seconds.

Finance still needs to reconcile it.

Accounting records the sale elsewhere.

Inventory lives in another system.

Refunds follow another workflow.

Treasury checks settlement through a different portal.

The customer sees one digital experience.

The business operates several disconnected systems behind it.

That is why APIs matter.

Fast payment does not automatically mean efficient operations

After a payment succeeds, multiple operational questions remain.

Has the order status changed?

Has inventory been reduced?

Has the sale reached accounting?

Has a receipt been created?

When will settlement arrive?

How is the fee recorded?

What happens if the transaction is refunded?

If people still reconcile those steps manually, much of the productivity benefit is lost.

The next stage of payments is therefore about information flow, not merely payment speed.

Indonesia already has a national API standard

Bank Indonesia established the National Open API Payment Standard, SNAP, in 2021.[1]

SNAP standardises important technical and security components including communication protocols, API architecture, data formats, authentication, authorisation, encryption, access management and request-response structures.[1]

It also includes governance principles around consumer protection, data protection and prudential requirements.

The objective is interoperability, integration, efficiency and security.

SNAP is not new in 2026

This distinction matters.

SNAP did not begin with FEKDI 2026.

Its governance was transferred from Bank Indonesia to the Indonesian Payment System Association, ASPI, effective September 1, 2023.[1]

What changed in 2026 is the wider regulatory architecture.

Bank Indonesia Regulation No. 10/2025 and Board of Governors Regulation No. 32/2025 took effect on March 31, 2026.[2][3]

They cover the payment industry far beyond APIs: activities, products, pricing, industry structure, technology, governance, risk, data and cooperation.

Why APIs matter outside financial institutions

An API sounds technical.

Its business effect is not.

Retail wants payments connected to POS.

Hotels want settlement connected to bookings.

Marketplaces need refunds connected to orders.

Distributors want collections connected to ERP.

Treasury wants incoming funds reflected in cash positions.

Software businesses want payment to trigger service provisioning.

Every manual bridge is friction.

APIs can remove some of it.

Standards reduce unnecessary variation

Without standards, every provider can expose a different data format, authentication method and integration logic.

Each new provider becomes a custom project.

That increases cost and maintenance.

Standards reduce the amount of difference businesses need to manage.

They do not make every implementation identical.

They create a more common foundation.

A standard does not guarantee a good API

Two providers can both follow a standard while delivering very different experiences.

Reliability.

Latency.

Documentation.

Error handling.

Sandbox quality.

Support.

Incident response.

All can differ.

Standard compliance is therefore a baseline.

Execution remains a competitive dimension.

Competitive advantage shifts into workflow

When basic payment acceptance becomes widely available, differentiation moves elsewhere.

How quickly can a merchant integrate?

How easily can it reconcile?

How reliable are callbacks?

Can refunds be automated?

Can accounting systems consume the data?

Is technical documentation clear?

This is where payment infrastructure increasingly affects business productivity.

POS, payment and accounting should behave like one flow

Consider a restaurant.

An order enters the POS.

Payment succeeds.

The POS marks it paid.

Inventory updates.

Accounting records revenue.

Settlement later reconciles.

The closer these steps come to one automatic flow, the more payment becomes infrastructure rather than a standalone channel.

Enterprise integration goes deeper

For larger companies, APIs can connect collections to accounts receivable, invoice matching, treasury and ERP.

At high transaction volumes, reducing even a small percentage of manual exceptions can save significant operating effort.

That turns API architecture into a financial-productivity issue.

Authentication and authorisation are business controls

APIs create access paths between systems.

Who can call the API?

For what purpose?

Which data?

Which action?

For how long?

How are credentials revoked?

SNAP specifically standardises authentication, authorisation, encryption and API-access management.[1]

These are not technical details.

They are controls.

Connectivity expands the attack surface

A connected ecosystem can transmit problems as well as data.

Compromised credentials.

Weak partner systems.

Excessive permissions.

Forged callbacks.

Poor rate controls.

Connectivity increases usefulness while increasing dependency.

Least privilege and strong partner governance therefore matter more as integration grows.

Operational failures can be just as damaging as cyberattacks

A transaction can succeed while the callback fails.

The POS still sees “unpaid”.

The customer retries.

A duplicate charge appears.

A refund follows.

Settlement no longer matches the order.

No hacker is required.

Poor integration alone can create customer loss and reconciliation problems.

Uptime is not enough

Enterprises should monitor more than whether an API is online.

Success rate.

Latency.

Timeouts.

Duplicate events.

Failed callbacks.

Reconciliation breaks.

Recovery time.

Availability that fails during peak periods can have a larger economic effect than a simple monthly uptime figure suggests.

Data should not move simply because it can

Open APIs make sharing easier.

That increases the importance of data minimisation.

If a system only needs transaction ID, amount and status, it may not need broader personal data.

SNAP’s governance framework includes data protection for exactly this reason.[1]

Technical connectivity does not erase consent

A customer agreeing to one service does not mean every connected company gains unrestricted rights over the data.

Purpose, consent, retention and security remain separate governance questions.

An API accelerates movement.

It does not expand legal permission by itself.

Open architecture can still create vendor lock-in

Technical openness and commercial portability are different.

A business can still become dependent on a provider because of custom logic, historical data, proprietary features and switching costs.

Companies should therefore think about exit design as well as integration design.

Design for switching

Can data be exported?

Are mappings documented?

Can the integration layer be reused?

Can two providers operate in parallel during migration?

What happens if a contract ends?

Architecture is more resilient when leaving does not require rebuilding everything.

Indonesia’s new regulation focuses on resilience too

Bank Indonesia Regulation No. 10/2025 covers payment activities, products, pricing, technology, industry structure, governance, risk, market conduct, consumer protection and data.[2]

The detailed Board of Governors Regulation implements that framework.[3]

The policy direction is not simply “more innovation”.

It is innovation inside a resilient system.

Connectivity can create systemic importance

The new framework also evaluates payment actors through criteria related to transactions, interconnection, competence, risk management and technology infrastructure.[2]

The logic is straightforward.

The more connected an actor becomes, the greater the consequences when that actor fails.

Integration creates value.

It also creates responsibility.

FEKDI comes at the right moment

Bank Indonesia scheduled FEKDI for September 24–26, 2026.[4]

Its August policy review also positioned FEKDI x IFSE within implementation of the Payment System Blueprint 2030.[5]

That makes the timing appropriate for a broader question.

Indonesia has already made strong progress in payment adoption.

The next competition is increasingly about how well that infrastructure fits into the economy around it.

More APIs are not automatically better

API count can become another vanity metric.

A company can advertise 150 APIs while few generate meaningful business outcomes.

The better measures are:

less manual reconciliation;

shorter partner onboarding;

fewer transaction errors;

faster financial close;

fewer settlement exceptions;

better customer resolution.

The API is only useful if it improves a process.

Integration debt is real

Too many point-to-point connections create complexity.

One provider connects directly to ERP.

Another to POS.

A marketplace uses a custom connector.

CRM receives data through another route.

Eventually every change affects several systems.

Businesses need architecture discipline:

common identifiers;

versioning;

ownership;

monitoring;

and clear interfaces.

CFOs should care about API design

Poor integration eventually appears in finance.

Unreconciled cash.

Manual work.

Delayed close.

Duplicate refunds.

Unclear working capital.

API architecture is therefore not just an IT topic.

It can affect financial control.

Product leaders should care too

Customers do not care which partner caused a failure.

They only see that payment failed or a refund did not arrive.

Third-party integration is part of the product experience.

Treasury may gain the clearest benefit

Connected payment data can improve cash visibility, collection matching and forecasting.

But only if identifiers are consistent and data quality is controlled.

Bad data connected faster is still bad data.

Build versus buy is not an ideological choice

Companies can integrate directly, use middleware, a payment gateway or an orchestration layer.

The right approach depends on scale, complexity, control, security, cost and internal capabilities.

The architecture should serve the operating model.

Questions before building an integration

What business outcome does it create?

Who owns it?

What data need to move?

What is the worst failure mode?

How will transactions reconcile?

How are retries handled?

Who responds to incidents?

How is access revoked?

What is the exit plan?

If those questions are unclear, the API may be premature.

Payments are digital. Now businesses need to become connected.

Indonesia already has national API standards.

Digital payments operate at scale.

The regulatory framework is maturing.

The next stage is not adding more disconnected digital layers.

It is connecting payment, order, inventory, accounting, treasury and service into coherent flows.

When integration works well, customers barely notice it.

That is often the clearest sign of successful infrastructure.

The best integration is not the one users can see. It is the one that makes complexity disappear.