Skip to main content
Charges are debit transactions that pull funds from a customer’s bank account through the ACH network. This guide covers the complete charge lifecycle—from creation through settlement—including status management, balance verification, and handling returns.
Charges are ACH debit transactions that require proper customer authorization. Understanding ACH basics helps ensure compliant implementation and reduces return rates.

What You’ll Learn

This comprehensive guide will walk you through:
  • Creating charges with required fields and optional configurations
  • Understanding the payment status lifecycle and when charges can be modified
  • Implementing balance verification to reduce NSF failures
  • Handling failures and returns with specific reason codes
  • Managing charges through hold, release, and cancellation operations
  • Testing charge scenarios in sandbox before production
Whether you’re implementing subscription billing, one-time purchases, invoice collection, or account funding, this guide provides the patterns and best practices for successful charge implementation.
Charges require a paykey - a token representing a verified bank account. Learn about connecting bank accounts in the Bridge guide.

The Charge Object

A charge represents a debit transaction with comprehensive status tracking and metadata:

Core Fields

Creating a Charge

View detailed schema and request information on the Create a Charge API Reference

Required Parameters

string
required
Payment key for the customer’s verified bank account. Obtained via Bridge flow.
integer
required
Amount to charge in cents. Must be positive. Example: 10000 for $100.00
string
required
ISO 4217 currency code. Currently only "USD" is supported.
string
required
Description appearing on bank statements. Maximum 80 characters. Be clear and recognizable.
string
required
Date to process payment (YYYY-MM-DD). Can be today or future-dated up to 90 days.
How customer consent was obtained:
  • "internet" - Online or mobile app authorization
  • "signed" - Signed agreement or contract
  • "telephone" - Phone authorization
Learn more about authorization requirements and the difference between internet vs. contract authorization for ACH compliance.
object
required
Customer device information for fraud prevention.
string
required
Your unique identifier for this charge. Must be unique across all charges. Used for idempotency.
object
required
Processing configuration options.

Optional Parameters

object
Custom key-value pairs. Maximum 20 keys, 40 characters per key/value.

Payment Status Lifecycle

Charges progress through these statuses:
Critical: Once a charge reaches pending status, it has been submitted to the payment network and CANNOT be stopped, held, or cancelled.

Status Details

Every status change includes detailed information:
For complete status reasons and ACH codes, see Payment Statuses Guide. Learn about ACH return codes and NACHA compliance for better error handling.

Common Operations

Retrieve a Charge

Update a Charge

Update charges in created or scheduled status:

Cancel a Charge

Cancel charges before they reach pending status:

Place on Hold

Pause a charge for review (only in created or scheduled status):

Release a Hold

Release user-initiated holds only:
System holds (watchtower source) cannot be released via API. They require manual review in the dashboard.

Resubmit a Charge

Re-attempt a charge using the resubmit endpoint. This creates a new transaction that inherits the original payment’s details.

Balance Verification

Balance checks help reduce NSF returns:
Balance verification is part of Straddle’s account validation process that helps reduce NSF returns and improve payment success rates.
required will fail charges if:
  • The paykey was created with manual bank account entry
  • The bank doesn’t provide balance information
  • Balance service is temporarily unavailable

Handling Failures

When charges fail, check status_details for specific information:

Testing in Sandbox

Use sandbox_outcome in the config to simulate scenarios:
Common test scenarios:
  • "paid" - Successful charge
  • "failed_insufficient_funds" - NSF failure
  • "on_hold_daily_limit" - Risk hold
  • "reversed_customer_dispute" - Post-funding reversal

Webhooks

Set up webhooks to receive real-time charge updates

Best Practices

Use Idempotency

Always include a unique external_id to prevent duplicate charges

Monitor Status Changes

Set up webhooks to track payment lifecycle in real-time

Handle Failures Gracefully

Implement retry logic for transient failures like NSF

Test Thoroughly

Use sandbox to test all failure scenarios before production

Next Steps

API Reference

Complete charge endpoint documentation

Payment Statuses

Detailed status flows and ACH codes

Payouts Guide

Learn about sending money to customers

Webhooks

Set up real-time notifications