QRIS API vs Payment Gateway API: Technical Differences, Response Time, and Retry Logic for Indonesian Developers

0.3% MDR vs P99 Latency: Why Your QRIS Integration Choice Defines System Architecture

When integrating QRIS payments, the 0.3% MDR for MSMEs often takes center stage. But for developers, the more critical number is your payment gateway's P99 latency. In production, the difference between direct QRIS API integration versus going through a payment gateway isn't just about costs—it's about how you handle 500ms+ response time during peak hours, retry with exponential backoff when APIs timeout, and ensuring the webhook callback you receive is actually valid.

This article breaks down the technical differences between direct QRIS API integration (like Direct QRIS from payment providers) versus using a payment gateway as an abstraction layer, focusing on response time, latency metrics, error handling patterns, and the retry logic you need to implement.

Direct QRIS API: Full Control with Its Own Complexity

Direct QRIS API integration means you interact directly with each payment provider's system (DANA, GoPay, OVO, ShopeePay, etc). This approach gives you full control over the payment flow, but comes with significant complexity.

First, you must implement proper retry logic yourself. According to DANA API documentation, QRIS retry best practice is using exponential backoff with maximum 25 retry attempts, and it's crucial to use the same partnerReferenceNo when retrying. This means you can't just resend the same request—you need to design a system that can track unique references per transaction and carefully manage retry timing.

Second, after receiving a QRIS callback, you're required to verify status using the Status Inquiry API to ensure transaction integrity. NICEPAY API documentation emphasizes that callbacks cannot be considered final without active verification. This adds one API round-trip per successful transaction, impacting total response time and server load.

Third, you need to manage metrics monitoring on your own. Payment gateway providers typically monitor metrics like average response time, P95/P99 latency, and response time per endpoint for their SLAs. With direct integration, you must build dashboards and monitoring yourself to ensure external APIs perform well and detect anomalies before they impact users.

Payment Gateway Abstraction: Standardization with Latency Tradeoffs

Payment gateways like Midtrans and Xendit act as abstraction layers that unify various payment methods, including QRIS, into more consistent APIs. Midtrans supports 24+ payment methods with 1-2 business day settlement, while Xendit offers more modern APIs with 1-3 business day settlement.

The main advantage is consistency. You don't need to learn and integrate different APIs for each QRIS provider. A single payment gateway endpoint can handle multiple QRIS providers behind the scenes. This saves significant development and maintenance time, especially if you need to support various payment methods beyond QRIS.

But there's a tradeoff: additional latency. Each request passes through one extra layer—from your system to the payment gateway, then from the gateway to the QRIS provider, then back again. In normal cases, this might only add 100-200ms. But during peak hours or when one QRIS provider experiences slowdowns, this latency can balloon significantly. If the payment gateway doesn't forward original provider latency metrics, you lose visibility into the actual bottleneck.

Payment gateways also have different retry rules and rate limiting. Some forward retries directly to QRIS providers, others implement internal queues. You need to understand how your chosen gateway handles retries and errors, as this impacts how you design your own system—whether you need to retry on your side, or rely solely on the gateway's retry mechanism.

Response Time and Latency Metrics: What to Monitor

For robust QRIS integration, you can't rely on a single latency metric. Professional payment gateways monitor three main metrics: average response time, P95/P99 latency, and response time per endpoint. Each provides different insights.

Average response time gives a general performance picture, but can be misleading with extreme outliers. P95 and P99 latency are far more important for user experience—they show the performance experienced by 95% and 99% of requests. If your QRIS P99 latency is 3 seconds, that means 1 in 100 users experiences significant delays, which can heavily impact conversion rates.

Response time per endpoint helps identify specific bottlenecks. Is the QRIS generate endpoint slow, or is the status inquiry endpoint problematic? With direct QRIS API integration, you can monitor this granularly. With payment gateways, you often only see gateway latency itself, without visibility into where time is actually spent.

For healthy integration, target P95 latency below 1 second for QRIS generation, and P99 below 2 seconds for status inquiry. Anything above this, you need to consider retry logic, circuit breakers, or fallback to other payment methods. Proper monitoring also helps detect degradation early—before users start complaining.

Retry Logic, Exponential Backoff, and Idempotency

Network failures, timeouts, and 500 errors from payment APIs are normal. Robust systems must be designed assuming failures will occur. The question is how you handle these failures without disrupting users or creating duplicate transactions.

Good QRIS retry logic follows exponential backoff principles: wait progressively longer between each retry. If the first retry is after 1 second, the next after 2 seconds, then 4 seconds, and so on. DANA documentation recommends maximum 25 retry attempts—enough to handle short-term fluctuations, but not indefinitely for systems down for hours.

The key to safe retry is idempotency: the same request sent multiple times should produce the same effect as if sent once. For QRIS, this means using the same partnerReferenceNo or reference ID for each retry of the same transaction. This way, even if your system sends 10 requests due to network issues, the QRIS provider will recognize this as the same transaction—not 10 separate transactions.

Implementing idempotency typically requires a database layer that can check whether a reference ID has been used before processing a new request. If it exists, your system can return the existing result without calling the external API again. This not only prevents duplication but also saves API quota and improves response time for retry requests.

Webhook Idempotency and Status Inquiry: Verification is Key

Callbacks or webhooks from QRIS providers are the most efficient way to know payment status is complete. But callbacks can't be fully trusted—network failures, replay attacks, or even fake callbacks are real risks. That's why NICEPAY documentation emphasizes that after receiving a QRIS callback, you must verify status using the Status Inquiry API.

Implementing webhook idempotency requires a two-step approach. First, when callback is received, save the information to database with "pending-verification" status. Second, immediately call Status Inquiry API to confirm. If status inquiry matches the callback, update to final status. If not, investigate further or mark as suspicious.

This pattern adds complexity, but is critical for financial integrity. Without verification, your system could be tricked with fake callbacks claiming successful payment. With verification, you always have a single source of truth from Status Inquiry API—far harder to fake because it requires authentication and comes directly from the payment provider.

When to Choose Direct Integration vs Payment Gateway

The decision between direct QRIS API integration or using a payment gateway depends on your scale, team resources, and business needs complexity. For startups with small teams needing fast go-to-market, payment gateways like Midtrans or Xendit often make more sense—you get standardization, better documentation, and one integration for multiple payment methods.

However, for mature businesses with high transaction volumes and strong engineering teams, direct integration to major QRIS providers can provide better cost leverage and control. QRIS MDR is regulated by Bank Indonesia—0.3% for MSMEs and 0.7% for regular merchants, same for everyone—but payment gateways may add additional fees on top. With direct integration, you can avoid these fees and fully control the payment flow.

Another consideration is technical support. With payment gateways, you have one contact point for payment issues. With direct integration, you need to coordinate with multiple providers if problems occur. For small teams, this can become significant overhead.

Regardless of your choice, the key to successful QRIS integration is proper monitoring, robust retry logic, and strict verification. Without all three, even the most expensive integration will experience issues impacting the business.

If you need help designing a robust payment system architecture for your business, the Colabs team is ready to assist. We have experience integrating various payment methods, including QRIS, with an approach that considers performance, security, and long-term scalability. Contact us for free consultation on your payment system needs.