Nocturne $0.30 Per-Payment Fees: What Happens With Retries, Partials, and Reversals?

Nocturne charges a flat $0.30 per-payment fee retries can multiply when each retry reaches processing. A merchant running N separate authorization or capture attempts on the same intended checkout should model roughly $0.30 × N. Partials and reversals depend on whether they create additional processed payment events.

The $0.30 rule in one sentence

The Nocturne rule is simple: the fee is assessed per payment attempt, not per customer order, shopping cart, invoice, or subscription period.

A payment attempt means each distinct authorization, capture, or payment run that the card rails process for a Nocturne virtual card. If the merchant sees one checkout, but its gateway, processor, or internal payment logic runs the card three separate times, the cost model is three fee events:

3 processed attempts × $0.30 = $0.90

This is the key distinction for merchant payment operations. A shopper may click “Pay” once, but the checkout system may do more work behind the scenes: an initial authorization, a retry after a soft decline, a second capture request, or a reattempt after a void or reversal. The relevant number is the checkout attempt count that reached processing, not the number of orders displayed in the commerce platform.

For users, Nocturne is a no-KYC virtual debit product: no ID / no KYC onboarding, on-chain funding, no bank account or exchange login, card minting in about 60 seconds, tokenized card number, and the merchant sees card, not user. For merchants and payment teams, the operational cost question is narrower: how many times did the Nocturne virtual card transaction actually run through authorization and capture processing?

That is where fee stacking appears. If one order creates multiple retry attempts, the flat $0.30 per-payment fee can stack in $0.30 increments.

Does Nocturne charge $0.30 per order or per payment attempt?

Nocturne charges the flat $0.30 per-payment fee per payment attempt, not per order.

A single customer order can map to one attempt, two attempts, or many attempts depending on the merchant’s payment flow. The same $80 cart might produce:

• 1 successful authorization and capture: $0.30
• 1 failed authorization and 1 successful retry: $0.60
• 1 failed authorization and 3 retry attempts before success: $1.20
• 1 authorization followed by 2 processed partial captures: $0.60 if those captures are treated as distinct payment events
• 1 attempted capture, a reversed capture, then 1 new capture attempt: $0.60

The phrase “per order” is not accurate for modeling payment retries cost. A cleaner internal formula is:

Nocturne fee exposure = processed attempt count × $0.30

That formula is intentionally operational. It tells payment teams to count events, not carts.

What changes the fee count: retries vs partials vs reversed captures

The total depends on which events reach the issuer or network processing step. A validation failure that never submits to the card rails may not be a payment attempt. A separate authorization or capture that does submit is generally the kind of event merchants should count.

1) Retries: authorization or capture retry attempts

Retries are the most common way the total rises. If a payment fails and the merchant automatically retries the authorization, each retry that actually runs is another processed attempt.

If a merchant retries a failed authorization, how many $0.30 fees apply? Count the original processed attempt plus each processed retry. For example:

• Initial authorization fails: $0.30
• Retry 1 fails: additional $0.30
• Retry 2 succeeds: additional $0.30
• Total: $0.90

This is true even if the merchant treats the flow as one order recovery. The customer intended one checkout, but the payment system ran three attempts.

A useful cost distinction is soft-decline retry behavior versus hard-stop behavior:

• Soft-decline style retry behavior: the merchant may retry after a delay, after a billing-field correction, or after a temporary issuer response. This can preserve approval rate, but it increases the fee count when retries reach processing.
• Hard stop: the merchant stops after one clear decline category or after a fixed limit. This caps fee exposure, but it may reduce recovered payments if the decline was temporary.

For Nocturne fee modeling, a retry storm is expensive not because the fee is high per attempt, but because the number of attempts grows quickly. Six processed attempts on one checkout equal $1.80 in Nocturne fees.

2) Partial captures: split fulfillment and multiple captures

Partial capture flows also change the total. A partial capture occurs when the merchant captures less than the full authorized amount, often because items ship separately or only part of the order is fulfilled.

How do partial captures affect total $0.30 fees? If a single authorization leads to one final capture, the fee model usually stays closer to one processed payment event. If the merchant performs multiple captures as separate payment events, each processed capture can add another $0.30.

Mini rule:

• One authorization with one final capture: usually closer to one fee event.
• One authorization with multiple captures: generally model as $0.30 × number of processed capture events if those captures run as distinct payment events.

Example:

• Order total: $120
• Capture 1 for shipped item A: $70
• Capture 2 for shipped item B: $50
• If processed as two distinct capture events: 2 × $0.30 = $0.60

Partial capture fees become more relevant in marketplaces, split shipments, backorders, preorders, and any system where fulfillment events are separated from the original checkout.

3) Reversed captures, reversals, and voids

A reversed capture or void does not automatically erase the fact that processing occurred. Nocturne’s fee logic should be modeled around attempted processing, not whether the merchant later reversed the transaction.

If a capture is reversed, are any $0.30 fees already incurred? If the capture attempt reached processing, merchants should assume the $0.30 fee event may already have occurred. A later reversal, void, or capture reversal handling step changes the payment lifecycle, but it does not necessarily remove the original attempt from the count.

This is especially important for systems that do a capture, reverse it because of inventory or fraud screening, and then run another capture later. From a fee model perspective:

• Attempted capture: $0.30
• Reversal or void after the attempt: does not necessarily remove the attempted-processing event
• New capture attempt: additional $0.30
• Total model: $0.60

The operational question is not simply “Was the order eventually paid?” It is “How many authorization, capture, void, reversal, and reattempt events did we process?”

Price table: Nocturne $0.30 fee by event pattern

The table below gives practical ranges for common checkout patterns. These are fee-modeling ranges for the Nocturne flat $0.30 per-payment fee, using typical operational patterns such as 1–6 retry attempts and 1–3 partial captures.

Item	Typical processed attempt pattern	Price range
Successful single payment	1 authorization/capture flow that runs once	$0.30
Failed payment with no retry	1 processed failed attempt	$0.30
Failed/retried payments	2–6 processed attempts	$0.60–$1.80
N-attempt recovery	N processed attempts	$0.30 × N
1 failed + 1 retry succeeds	2 processed attempts	$0.60
1 failed + 3 retries before success	4 processed attempts	$1.20
Partial captures, k captures	1–3 processed capture events	$0.30–$0.90
Reversal/void after attempted processing	1 original attempt, plus any reattempts	$0.30–$0.60+
Subscription-like intermittent declines	3–6 processed attempts in a billing period	$0.90–$1.80

Use the table as a counting framework, not as a replacement for your processor logs. The decisive variable is whether an event became a processed payment attempt.

What drives the price up or down

The primary driver is the number of distinct payment attempts that reach processing. Every processed attempt adds another $0.30.

Primary driver: processed attempt count

The cheapest flow is one clean attempt:

1 × $0.30 = $0.30

Costs rise linearly:

• 2 attempts: $0.60
• 3 attempts: $0.90
• 4 attempts: $1.20
• 5 attempts: $1.50
• 6 attempts: $1.80

This makes retry count modeling straightforward. The merchant does not need a percentage-based interchange-style estimate for Nocturne’s fee. The fee is flat. The total depends on how many attempts run.

Secondary driver: partial capture strategy

The second driver is capture design. Merchants that capture once usually keep the fee count lower. Merchants that split fulfillment into several capture events should expect the fee count to rise when those captures are processed as separate payment events.

For example:

• One capture for a $150 order: $0.30
• Three separate captures for the same $150 order: $0.90

The order value does not change the Nocturne fee. The number of processed capture events does.

Operational levers: retry throttling and early stop rules

Merchants can reduce exposure by controlling retry behavior:

• Set a maximum retry count per order.
• Use delay or backoff instead of immediate repeated retries.
• Stop after clear hard-decline categories.
• Avoid gateway configurations that automatically re-run the same payment too many times.
• Separate customer-correctable errors from issuer/network responses.
• Consolidate fulfillment where practical to reduce multiple captures.

How can merchants reduce $0.30 fee exposure without tanking approval rate? The best approach is to cap retries while preserving high-quality recovery attempts. For example, a merchant might allow one immediate retry for a temporary response, then one delayed retry after updated customer input, but block repeated attempts in a short window. That gives the merchant a path to recover intermittent declines without creating a retry storm.

Real scenarios with numbers: Nocturne $0.30 fee totals

These examples assume each listed event reaches processing and therefore triggers a $0.30 fee event.

Scenario A: 1 failed attempt, then 1 retry succeeds

A customer enters card details for a Nocturne virtual card. The first authorization fails because of a temporary response. The merchant retries once and the second attempt succeeds.

• Attempt 1: failed authorization = $0.30
• Attempt 2: successful retry = $0.30
• Total Nocturne fee: $0.60

This is the simplest retry recovery model:

2 attempts × $0.30 = $0.60

Scenario B: 1 failed attempt, then 3 retries before success

The merchant’s gateway runs the original attempt, then automatically retries three times before one succeeds.

• Attempt 1: failed = $0.30
• Attempt 2: retry fails = $0.30
• Attempt 3: retry fails = $0.30
• Attempt 4: retry succeeds = $0.30
• Total Nocturne fee: $1.20

What’s the cost impact of running 1, 2, 3, or 4 retries? Assuming the original attempt also ran:

• Original + 1 retry = 2 attempts = $0.60
• Original + 2 retries = 3 attempts = $0.90
• Original + 3 retries = 4 attempts = $1.20
• Original + 4 retries = 5 attempts = $1.50

This is why payment teams should distinguish “retry count” from “total attempt count.” Four retries after an original failure means five attempts, not four.

Scenario C: Subscription-like flow with 5 attempts in a month

A subscription-like billing flow runs several payment attempts during a month because of intermittent declines. Assume all five attempts reach processing.

• Attempt 1: $0.30
• Attempt 2: $0.30
• Attempt 3: $0.30
• Attempt 4: $0.30
• Attempt 5: $0.30
• Total Nocturne fee: $1.50

How should a merchant model expected fee cost for intermittent declines? Use:

expected fee = expected processed attempts × $0.30

If a merchant expects 1.8 attempts per successful subscription payment on average, the expected Nocturne fee is:

1.8 × $0.30 = $0.54

If the merchant expects 4 attempts for a harder-to-recover account, the expected fee is:

4 × $0.30 = $1.20

The model stays linear.

Scenario D: Partial fulfillment with 2 captures

A merchant authorizes an order, then ships in two batches and processes two captures.

• Capture 1: $60 shipment = $0.30
• Capture 2: $40 shipment = $0.30
• Total Nocturne fee: $0.60

This assumes the two captures are processed as two distinct payment events. If the merchant can combine fulfillment into one capture, the modeled fee could remain closer to $0.30.

Scenario E: Attempted capture is reversed, then reattempted once

A merchant captures a payment, reverses it because of an internal issue, then reattempts the capture.

• Original attempted capture: $0.30
• Reversal event: does not automatically erase the original attempted fee event
• New capture attempt: $0.30
• Total Nocturne fee model: $0.60

This is the practical reversed capture fee treatment: count the processed attempt that was reversed, then count the new attempt if one runs.

Authorization vs capture: where merchants should count events

Authorization vs capture matters because different merchant systems treat them differently.

An authorization checks whether the card can be approved for a given amount. A capture finalizes the movement of funds against an authorization or as part of a sale flow. Some merchants use immediate sale transactions where authorization and capture happen together. Others authorize first, then capture later.

What payment lifecycle events should be instrumented to count fee events? At minimum, log:

• Initial authorization request
• Authorization retry attempts
• Authorization reversals or voids
• Capture request
• Capture retry attempts
• Partial capture events
• Multiple captures tied to one order
• Reversed capture events
• Reversal and void timestamps
• Gateway response code and decline category
• Whether the event reached issuer/network processing
• Internal order ID and checkout attempt count

The last item is often missing. Merchants commonly know order count and gross merchandise value, but not checkout attempt count. For Nocturne fee forecasting, checkout attempt count is the core metric.

If only the capture is retried after an auth fails, does the $0.30 fee charge again? In a normal payment lifecycle, a capture follows an approved authorization; if an authorization failed, there may be no valid capture to retry. But if the merchant system runs a new processed payment event—whether labeled a capture retry, sale reattempt, or another authorization/capture path—model another $0.30 fee for that processed attempt.

Practical merchant checklist to estimate Nocturne fee exposure

Use this checklist to turn logs into a fee estimate.

1) Build an attempt ledger

Create a per-order ledger that records every processed payment event. The ledger should not only store the final transaction status. It should preserve all attempts, including failed authorizations, capture retries, voids, reversals, and reattempts.

Minimum fields:

• Order ID
• Customer checkout session ID
• Attempt number
• Event type: authorization, capture, partial capture, reversal, void
• Amount
• Gateway response
• Timestamp
• Whether the request reached processing
• Nocturne fee assumption: $0.30 or $0.00

2) Separate blocked validations from processed attempts

Not every checkout error is a processed payment attempt. For example, a missing ZIP field rejected by the merchant form before submission is not the same as a card authorization sent to the rails.

For accurate modeling, separate:

• Pre-submit validation errors
• Gateway-side formatting rejections before processing
• Processed card authorizations
• Processed captures
• Processed reversals or void-related payment events

The fee per payment attempt applies to attempts that actually run. Your logs should mark that boundary.

3) Cap retries with business-specific rules

Avoid unlimited automatic retries. A simple structure might be:

• Attempt 1: original checkout
• Attempt 2: immediate retry only for temporary or ambiguous responses
• Attempt 3: delayed retry only after customer action or a short cooling period
• Stop after hard decline, repeated mismatch, or maximum attempts

This keeps the fee path predictable:

• Maximum 2 attempts: $0.60 cap per order
• Maximum 3 attempts: $0.90 cap per order
• Maximum 4 attempts: $1.20 cap per order

4) Reduce unnecessary partial captures

Partial captures are sometimes necessary. Split shipments, preorders, and item-level fulfillment can require them. But merchants should know the cost implication.

If three fulfillment events can be consolidated into one capture without harming operations, the Nocturne fee model moves from:

3 captures × $0.30 = $0.90

to:

1 capture × $0.30 = $0.30

5) Review reversal and void workflows

Void and reversal flows should be logged clearly. The problem is not that a reversal exists; it is that payment teams often fail to tie the reversal back to the original attempted capture and any later reattempt.

For each reversed payment, ask:

• Did the original authorization or capture reach processing?
• Was the reversal a void before settlement or a post-capture reversal?
• Did the system run a new authorization or capture afterward?
• How many total fee-causing attempts occurred?

Why this matters for Nocturne virtual card acceptance

Nocturne Shadow costs $25 and Nocturne Aurora costs $50. After minting, the operational payment fee is the same flat $0.30 per payment event. There is no monthly fee. Users fund on-chain and can spend with a no-KYC virtual debit card without a bank account or exchange login.

For merchants, the Nocturne acceptance question is not a percentage-cost problem. A $20 payment and a $200 payment have the same Nocturne per-payment fee exposure if they use the same number of processed attempts. The cost difference appears when the payment flow creates retry attempts, partial capture events, or reversed capture reattempts.

That makes Nocturne easy to model if merchant logs are clean:

total Nocturne fee = count of processed fee-causing attempts × $0.30

If your system does not currently expose processed attempt count, add it before trying to optimize acceptance. Without that metric, teams may confuse approval-rate issues with cost issues.

For background on the product itself, see Nocturne, which offers crypto-funded no-KYC virtual debit cards with tokenized card numbers.

FAQ

Does Nocturne charge $0.30 per order or per payment attempt?

Per payment attempt. One order with one processed attempt costs $0.30. One order with four processed attempts costs $1.20. Count authorization, capture, and retry events that actually reach processing.

If a merchant retries a failed authorization, how many $0.30 fees apply?

Model one $0.30 fee for the original failed authorization plus one $0.30 fee for each processed retry. Original failure plus two retries equals three attempts, or $0.90.

How do partial captures affect total $0.30 fees?

If partial captures are processed as distinct payment events, each can add $0.30. Two captures model as $0.60; three captures model as $0.90. A single final capture usually keeps the count lower.

If a capture is reversed, are any $0.30 fees already incurred?

If the capture attempt reached processing, merchants should assume a $0.30 fee event may already be incurred. A reversal or void does not automatically remove the fact that the original attempt occurred.

How should merchants reduce $0.30 fee exposure without hurting approvals?

Use controlled retries: cap the number of attempts, apply backoff, stop on hard-decline patterns, and consolidate captures when possible. The goal is to recover plausible soft declines while preventing repeated unnecessary processing attempts.