DEV Community: Suyash Dhakal

Same Request Sent Twice: How Idempotency Prevents Duplicate Payments

Suyash Dhakal — Sun, 16 Aug 2026 19:51:05 +0000

A user opens a payment app, types in an amount, and taps "Pay." The spinner shows up. Then nothing — no success screen, no error, just a frozen loader.

So they tap "Pay" again. Or the app quietly retries in the background because it never got a response.

But here's the actual problem: what if the first request actually reached the server and the payment already went through, and only the response got lost on the way back? The second tap now sends the same payment again. Does the user get charged twice?

This isn't a rare edge case. Mobile connections drop, servers get slow under load, requests time out. Any system that moves money over a network runs into this.

The idea that fixes it

The concept here is idempotency.

An operation is idempotent if running it twice has the same effect as running it once. Send the same request again, retry, double tap, whatever, and the outcome shouldn't change.

Pressing an elevator button five times doesn't call five elevators. The building registers your request once. A payment should work the same way: the button might get tapped repeatedly, but the money should move once.

The server doesn't ignore the repeat request. It just recognizes it as a repeat instead of treating it as something new.

Why payments care about this more than most systems

If a retried request reloads a page or re-fetches some data, nobody gets hurt. Payments are different, because the thing being repeated moves real money.

A typical failure looks like this:

User
  ↓
Payment API
  ↓
Payment processed
  ↓
Response is lost
  ↓
User/app retries
  ↓
Same payment request reaches the server again

Look at where it breaks. The payment succeeded. The server did its job. The failure happened after that, somewhere between the server and the user's phone. From the server's side everything is fine. From the user's side, nothing happened — so retrying feels like the obvious move.

That's why the backend can't assume every incoming request is a brand-new payment. A slow network plus one retry, and someone's account gets debited twice for something they bought once. In fintech that's not a glitch, it's a refund, a support ticket, and a user who stops trusting the app.

The idempotency key

So how does the server tell "I already did this" apart from "this is new"?

With an idempotency key — a unique value the client generates and attaches to that specific payment attempt. Usually it's sent as an HTTP header:

POST /payments
Idempotency-Key: abc123
Content-Type: application/json

{
  "amount": 100,
  "currency": "NPR"
}

The key itself is just a unique string. The important rule is that a retry reuses the same key instead of generating a fresh one.

First attempt:

Idempotency-Key: abc123
        ↓
Server receives request
        ↓
Server processes payment
        ↓
Server stores the result associated with abc123

The server now has a record saying "abc123 was handled, and here's what happened."

Response gets lost, app retries with the same key:

Idempotency-Key: abc123
        ↓
Server receives request
        ↓
Server recognizes the key
        ↓
Does not create another payment
        ↓
Returns the previous result

No new charge, just a slightly late confirmation for the user. The key is the thing that lets the server link the retry back to the original attempt.

A few things worth knowing about the key

Same key plus same operation means retry. A different key means a different operation — which is what lets someone genuinely pay the same amount twice on purpose. They'd just be sending two different keys.

But same key with a different payload isn't a retry — that's a bug. Say abc123 is used for a Rs. 100 payment, then shows up again with a Rs. 500 request. The server shouldn't just return whatever it stored the first time. Stripe, for example, checks for this: same key with matching parameters returns the original response, but a mismatch returns an error instead of processing it.

The server also has to store and check these keys reliably. This is usually a database, often with a unique constraint on the key, so two identical requests arriving at nearly the same time can't both slip through.

There's a timing gap hiding in that too. What if a second request with abc123 lands while the first one is still being processed, before there's even a stored result yet? Most systems handle this with a lock on the key — the second request waits, or gets bounced with a 409 telling the client to try again shortly.

The two situations side by side

Without idempotency:

User sends payment
      ↓
Payment succeeds
      ↓
Response is lost
      ↓
User retries
      ↓
Server processes it again
      ↓
Possible duplicate payment

With idempotency:

User sends payment with key ABC
      ↓
Payment succeeds
      ↓
Response is lost
      ↓
User retries with key ABC
      ↓
Server recognizes ABC
      ↓
Previous result is returned
      ↓
No duplicate payment

The trigger is identical in both — a lost response and a retry. The only difference is whether the server blindly repeats the work or notices the repeat.

How you'd actually test this

You can read about idempotency all day. Testing it is different. Here's where to start if you're testing a payment flow:

Double-tap it. Send the same request twice, back to back, same key. Only one charge should go through.
Cut the response, not the request. Let the server finish processing, but kill the connection before the response comes back. Retry with the same key. Do you get the old result, or does it run again?
Reuse the key, change the amount. Send abc123 for Rs. 100, then abc123 again for Rs. 500. Does it error out, return the first result anyway, or actually process Rs. 500?
Fire both at once. Send two identical requests with the same key at the same time. See if both slip through before either one finishes.
Skip the header. Send the request without Idempotency-Key at all. Check if the API rejects it, or just runs it like normal.

Wrapping up

A request being sent twice doesn't mean the operation should happen twice. Networks are unreliable, users retry, apps retry automatically. None of that is avoidable, and none of it is unusual.

In payments, this matters even more. Sending the same payment twice can mean charging someone twice. Idempotency is simply a way to make those retries safe.

In the end, idempotency is about one simple thing: making sure a retry doesn't turn into a duplicate operation.

Estimating Pi: A Monte Carlo Approach Enhanced by OpenMP Parallelism

Suyash Dhakal — Tue, 15 Oct 2024 11:10:32 +0000

Image credit: domin_domin via iStock

What if I told you that the seemingly random nature of points can be harnessed to calculate one of mathematics’ most famous constants — π? In this blog, we will explore how the Monte Carlo method can be used to estimate the value of π, an essential constant in mathematics and physics. We will also examine how OpenMP parallelism enhances the efficiency of the Monte Carlo approach.

Understanding the Monte Carlo Method

Monte Carlo methods are a broad class of computational algorithms that rely on repeated random sampling to obtain numerical results. They are widely used in various fields, including statistics, finance, physics, and engineering, to solve problems that may be deterministic in nature but are difficult to solve analytically.

One interesting application of the Monte Carlo method is the estimation of π. By randomly generating points within a unit square and determining how many of those points fall within a quarter circle inscribed in that square, we can derive an estimate for π.

Algorithm for Estimating π

Draw a unit square and inscribe a quarter circle within it.
Randomly generate points within the square.
Count the number of points that fall within the quarter circle by checking whether x²+y²≤1.
Calculate the ratio of points inside the circle to the total points, which approximates π/4.
Estimate π by multiplying the ratio by 4.

Monte Carlo method applied to approximating the value of π

Parallel Implementation of Monte Carlo Method

By distributing the workload across multiple threads, the parallel implementation of the Monte Carlo method using OpenMP significantly reduces computation time, especially when handling large datasets. This approach allows for scaling the number of points generated, achieving a more accurate approximation of π. Below is the implementation of the parallel Monte Carlo method for estimating π using OpenMP.

#include <stdio.h>
#include <stdlib.h>
#include <omp.h>

int main() {
    long int n;
    long int count = 0;
    long double x, y, z;
    double start, end, wall_clock_time;

    printf("\nn = ");
    scanf("%ld", &n);

    omp_set_num_threads(8); // Set the number of threads

    // True random numbers from random.org (based on atmospheric noise)
    unsigned int true_random_numbers[8] = {74, 51, 54, 89, 54, 15, 23, 31};

    start = omp_get_wtime(); // Record the start time

    #pragma omp parallel
    {
        // Seed each thread once
        unsigned int seed = true_random_numbers[omp_get_thread_num()]; 
        long int local_count = 0;

        #pragma omp for private(x, y, z)
        for(long int i = 0; i < n; ++i) {
            x = (long double)rand_r(&seed) / RAND_MAX; // Generate random x in [0, 1]
            y = (long double)rand_r(&seed) / RAND_MAX; // Generate random y in [0, 1]
            z = x * x + y * y; // Check if inside the unit circle

            if(z <= 1) {
                local_count++; // Count points inside the circle
            }
        }

        #pragma omp atomic
        count += local_count;
    }

    end = omp_get_wtime(); // Record the end time

    long double pi = (long double)count / n * 4; // Estimate of Pi
    printf("\nApproximate PI = %.9Lf\n", pi);

    wall_clock_time = end - start;
    printf("Elapsed Wall Clock Time: %f seconds\n", wall_clock_time);

    return 0;
}

The provided C program estimates the value of π using the Monte Carlo method, enhanced with parallel processing via OpenMP. It uses true random numbers sourced from random.org, generated using atmospheric noise to ensure high-quality randomness. Each thread is seeded once using the true_random_numbers[] array, allowing for independent and thread-safe random number generation with rand_r().

The workload is effectively distributed among threads using the#pragma omp for directive, enabling each thread to execute the Monte Carlo algorithm on its assigned set of iterations. Each thread maintains a private copy of the local count of points that fall within the quarter circle. After all threads complete their assigned tasks, the local counts are combined using an atomic operation to prevent race conditions. Finally, the estimated value of π is calculated by multiplying the ratio of points inside the circle by 4.

Experimental Results: Estimating π with 80 Billion Points

In the experiment conducted to estimate the value of π using a substantial sample size of 80 billion points , the Monte Carlo method was executed with n=80,000,000,000 (80 billion), yielding an approximation of π=3.141592614, accurate up to 7 decimal places , and took an elapsed wall clock time of approximately 235.32 seconds ( about 3.92 minutes ) to approximate π.

For comparison, the serial version of the algorithm was run with n=8,000,000,000 ( 8 billion ), resulting in an approximation of π=3.14160, accurate up to 3 decimal places, and took an elapsed time of 147.69 seconds ( about 2.46 minutes ).

This showcases a significant efficiency gain with the parallel implementation; the serial version would require approximately 24 to 25 minutes to approximate π for a sample size of 80 billion.

Experiment Setup:

Device: Apple MacBook Air
Chip: M2
RAM: 16GB
CPU: 8-core (4 efficiency cores, 4 performance cores)
Operating System: macOS Sonoma Version 14.6.1
Compiler: GCC 14 with OpenMP support

Convergence of the Monte Carlo Estimation of Pi

The convergence graph shows how the sample size affects the estimated value of π using the Monte Carlo method. As the sample size increases, the estimated value of π stabilizes around the true value of π, which is indicated by a red dashed line. For instance, with a sample size of 10, the estimate is 3.6, while at 1,000,000 samples, it improves to about 3.139. This trend highlights that larger sample sizes yield more accurate estimates, confirming the effectiveness of the Monte Carlo method for approximating the value of Pi.

Absolute Error vs. Sample Size

The absolute error graph illustrates how the sample size impacts the accuracy of the π estimation using the Monte Carlo method. As the sample size increases, the absolute error decreases significantly, indicating that larger sample sizes lead to more precise approximations. For example, with a sample size of 10, the absolute error is 0.458407, whereas, at a sample size of 1,000,000, the error drops to just 0.002537. This trend demonstrates the reliability of the Monte Carlo method in achieving high accuracy with sufficient sample sizes, confirming its effectiveness for approximating the value of π.

Conclusion

In this study, we applied the Monte Carlo method to estimate π using a sample size of 80 billion points, yielding an approximation of 3.141592614, accurate up to 7 decimal places. The results demonstrated the effectiveness of parallel computing in reducing computation time compared to serial implementation. Additionally, the analysis of convergence and absolute error confirmed that larger sample sizes improve accuracy, demonstrating the robustness of the Monte Carlo method for π approximation.