# Capture payment Source: https://docs.paymend.com/api-reference/endpoint/capture POST /api/v1/payments/{paymentId}/capture The capture endpoint has been created with the standard structure: * **Title**: "Capture payment" * **OpenAPI reference**: `POST /api/v1/payments/{paymentId}/capture` This follows the same pattern as your other endpoints (refund, void) and will integrate with your OpenAPI specification. The endpoint allows capturing a previously authorized payment to transfer the funds to the merchant's account. # Create payment Source: https://docs.paymend.com/api-reference/endpoint/payment POST /api/v1/payments # Get payment Source: https://docs.paymend.com/api-reference/endpoint/payment-details GET /api/v1/payments/{paymentId} # Refund payment Source: https://docs.paymend.com/api-reference/endpoint/refund POST /api/v1/payments/{paymentId}/refund # Void payment Source: https://docs.paymend.com/api-reference/endpoint/void POST /api/v1/payments/{paymentId}/void # Failure Codes Source: https://docs.paymend.com/api-reference/failure-codes Complete list of Paymend failure codes and their descriptions The following table lists all possible `failureCode` values that may be returned in the `failure` object when a payment fails. ## Failure Codes | Failure Code | Description | | :- | :- | | `ACCOUNT_AUTHENTICATION_FAILED` | CVV/PIN provided was incorrect or invalid | | `ACCOUNT_CLOSED` | Consumer's account has been closed | | `ACCOUNT_NUMBER_INVALID` | Consumer's account (eg. identified by card PAN) or issuing bank has not been recognized or does not exist | | `BLOCKED_BY_PAYMEND` | Payment blocked by Paymend | | `CARD_BLOCKED` | Card reported as lost or stolen | | `CARD_EXPIRED` | Card has expired | | `CARD_RESTRICTED` | Card has been restricted, contact issuing bank | | `DO_NOT_HONOR` | Transaction declined by issuer without providing a specific reason | | `EXCEEDS_AUTHORIZED_AMOUNT` | Value of capture request exceeds authorized amount | | `EXCEEDS_CAPTURED_AMOUNT` | Value of refund request exceeds captured amount | | `FORMAT_ERROR` | Error found in the format of the request | | `GENERIC_DECLINE` | Generic issuer decline | | `INSUFFICIENT_FUNDS` | There are not enough funds available in the consumer's account to authorize the transaction | | `INVALID_AMOUNT` | Transaction amount marked as invalid | | `INVALID_MERCHANT` | Invalid merchant | | `INVALID_TRANSACTION` | Transaction marked as invalid | | `PAYMENT_METHOD_NOT_SUPPORTED` | Payment method (or card brand) is not supported by Paymend | | `ROUTING_ERROR` | No route could be found to process the transaction | | `SECURITY_VIOLATION` | Transaction declined due to security or legal violation | | `SUSPECTED_FRAUD` | Transaction declined due to suspicion of fraud | | `TRANSACTION_NOT_PERMITTED` | Transaction not permitted | | `UNKNOWN_FAILURE` | Cause of failure is not yet mapped | | `PROVIDER_UNAVAILABLE` | Provider did not respond to the request | | `PROVIDER_PROCESSING_ERROR` | Provider experienced an error when attempting to process the transaction | | `INTERNAL_SERVICE_UNAVAILABLE` | A Paymend service did not respond to the request | | `INTERNAL_PROCESSING_ERROR` | Paymend experienced an error when attempting to process the transaction | # Address Source: https://docs.paymend.com/api-reference/objects/address Address information for billing or shipping The `Address` object contains location information used for billing or shipping addresses. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `street` | `string` | ❌ | Street address line | | `city` | `string` | ❌ | City or locality | | `country` | `string` | ❌ | Two-letter ISO 3166 country code (e.g., "US", "DE") | | `state` | `string` | ❌ | State, province, or region | | `zip` | `string` | ❌ | ZIP or postal code | ## Usage Address objects are used in: * **Billing** - Customer's billing address * **Shipping** - Delivery address for physical goods Address information helps with fraud prevention and may be required by some payment methods or regulations. # Billing Source: https://docs.paymend.com/api-reference/objects/billing Billing address information The `Billing` object contains the customer's billing address information. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `address` | [Address](/api-reference/objects/address) | ✅ | Billing address details | ## Usage Billing information is used for: * **Address verification** - Matching billing address with cardholder address * **Fraud prevention** - AVS (Address Verification Service) checks * **Compliance** - Some regulations require billing address verification * **Tax calculation** - For tax purposes in certain jurisdictions Accurate billing information helps improve payment success rates and reduces fraud risk. # CaptureRequest Source: https://docs.paymend.com/api-reference/objects/capture-request Request object for capturing authorized payments The `CaptureRequest` object is used to capture funds from a previously authorized payment. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `captureAmount` | `integer` | ❌ | Amount to capture in the smallest currency unit
**Notes:** Minimum value: 1, If omitted full authorization amount is captured, Cannot exceed originally authorized amount | ## Usage **Full Capture**: Omit the `captureAmount` field to capture the entire authorized amount. **Partial Capture**: Include `captureAmount` to capture a specific amount. ## Example - Full Capture ```json theme={null} {} ``` ## Example - Partial Capture ```json theme={null} { "captureAmount": 750 } ``` ## Business Rules * Capture can only be performed on authorized payments * Capture amount cannot exceed the authorized amount * Multiple partial captures are allowed until the full amount is captured * Once captured, funds are transferred to the merchant # Card Source: https://docs.paymend.com/api-reference/objects/card Credit/debit card payment method details The `card` object contains the credit or debit card information needed to process a payment. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `number` | `string` | ✅ | Card number (PAN), digits only | | `holderName` | `string` | ✅ | Name printed on the card | | `cvv` | `string` | ❌ | Card verification value (3-4 digits) | | `expiryMonth` | `string` | ✅ | Expiration month (01-12) | | `expiryYear` | `string` | ✅ | Expiration year (4 digits) | | `brand` | `string` | ❌ | Card brand (e.g., "VISA", "MASTERCARD", "AMEX") | ## Security Notes **Never store card details** - Always use tokenization for recurring payments. Card data should only be used for immediate processing. * Card numbers should be transmitted securely over HTTPS * CVV should never be stored after processing # Card response Source: https://docs.paymend.com/api-reference/objects/card-response Card payment method response details The `card` response object contains the card information returned in payment responses. Sensitive data is masked or represented as flags for security. ## Properties | Field | Type | Description | | :- | :- | :- | | `bin` | `string` | Bank Identification Number (BIN) - first 8 digits for Visa/Mastercard, first 6 digits for Amex | | `holderName` | `string` | Name printed on the card | | `cvvPresentDuringAttempt` | `boolean` | Indicates whether CVV was provided during the payment attempt | | `expiryMonth` | `string` | Expiration month (01-12) | | `expiryYear` | `string` | Expiration year (4 digits) | | `brand` | `string` | Card brand (e.g., "VISA", "MASTERCARD", "AMEX") | ## Security Notes **Sensitive Data Protection** - The `card` response object is designed to return only non-sensitive card information for security purposes. * **BIN Information**: Only the Bank Identification Number is returned, not the full card number * **CVV Status**: The `cvvPresentDuringAttempt` flag indicates whether CVV was provided without exposing the actual value * **Data Masking**: All sensitive card data is masked or excluded from responses * **PCI Compliance**: This response format helps maintain PCI DSS compliance by avoiding storage of sensitive card data ## Example ### `card` response ```json theme={null} { "bin": "41111111", "holderName": "John Doe", "cvvPresentDuringAttempt": true, "expiryMonth": "12", "expiryYear": "2025", "brand": "VISA" } ``` # Consumer Source: https://docs.paymend.com/api-reference/objects/consumer Customer information for payment processing The `Consumer` object contains information about the customer making the payment. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `firstName` | `string` | ✅ | Customer's first name | | `lastName` | `string` | ❌ | Customer's last name | | `email` | `string` | ✅ | Customer's email address | | `phone` | `string` | ❌ | Customer's phone number | | `ip` | `string` | ❌ | Customer's IP address (for fraud prevention) | ## Usage Consumer information is used for: * **Fraud prevention** - IP address and contact details help identify legitimate transactions * **Communication** - Email for receipts and notifications * **Compliance** - Some regulations require customer identification * **Analytics** - Understanding your customer base Providing accurate consumer information helps improve payment success rates and fraud detection. # Encrypted card Source: https://docs.paymend.com/api-reference/objects/encrypted-card Details of a credit/debit card payment method that is encrypted before sending the request to Paymend The `encryptedCard` object contains the credit or debit card information needed to process a payment. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `number` | `string` | ✅ | Encrypted card number (PAN) | | `holderName` | `string` | ✅ | Name printed on the card | | `cvv` | `string` | ❌ | Encrypted card verification value | | `expiryMonth` | `string` | ✅ | Expiration month (01-12) | | `expiryYear` | `string` | ✅ | Expiration year (4 digits) | | `brand` | `string` | ❌ | Card brand (e.g., "VISA", "MASTERCARD", "AMEX") | ## Security Notes **Never store card details** - Always use tokenization for recurring payments. Card data should only be used for immediate processing. # Encrypted card response Source: https://docs.paymend.com/api-reference/objects/encrypted-card-response Encrypted card payment method response details The `encryptedCard` response object contains the card information returned in payment responses. Sensitive data is masked or represented as flags for security. ## Properties | Field | Type | Description | | :- | :- | :- | | `bin` | `string` | Bank Identification Number (BIN) - first 8 digits for Visa/Mastercard, first 6 digits for Amex | | `holderName` | `string` | Name printed on the card | | `cvvPresentDuringAttempt` | `boolean` | Indicates whether CVV was provided during the payment attempt | | `expiryMonth` | `string` | Expiration month (01-12) | | `expiryYear` | `string` | Expiration year (4 digits) | | `brand` | `string` | Card brand (e.g., "VISA", "MASTERCARD", "AMEX") | ## Security Notes **Sensitive Data Protection** - The `encryptedCard` response object is designed to return only non-sensitive card information for security purposes. * **BIN Information**: Only the Bank Identification Number is returned, not the full card number * **CVV Status**: The `cvvPresentDuringAttempt` flag indicates whether CVV was provided without exposing the actual value * **Data Masking**: All sensitive card data is masked or excluded from responses * **PCI Compliance**: This response format helps maintain PCI DSS compliance by avoiding storage of sensitive card data ## Example ### `encryptedCard` Response ```json theme={null} { "bin": "55555555", "holderName": "Jane Smith", "cvvPresentDuringAttempt": false, "expiryMonth": "06", "expiryYear": "2026", "brand": "MASTERCARD" } ``` # Failure Source: https://docs.paymend.com/api-reference/objects/failure Details about the cause of a failed payment The `Failure` object contains failure codes which indicate why a payment has failed. ## Properties | Field | Type | Description | | | :- | :-: | :- | - | | `failureCode` | `string` | Paymend-defined code indicating the reason for failure. | | | `providerFailureCode` | `string` | **Optional** provider-defined code indicating the reason for failure. | | Details provided in the failure object can help you optimize your retrial strategy. The `failureCode` field aggregates provider responses so that you can base your internal logic on a single field. For card payments, we will pass the ISO-format code in `providerFailureCode` whenever it is received from our providers. # Payment Source: https://docs.paymend.com/api-reference/objects/payment Request object for creating a new payment The `Payment` object contains all the information needed to process a payment transaction. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `amount` | `number` | ✅ | Payment amount in the smallest currency unit (e.g., cents for USD) | | `currency` | `string` | ✅ | ISO 4217 currency code (e.g., "USD", "EUR") | | `paymentMethod` | [PaymentMethod](/api-reference/objects/payment-method) | ✅ | The chosen payment method details (e.g., card) | | `merchantReference` | `string` | ✅ | Merchant's unique identifier for this payment | | `source` | [Source](/api-reference/objects/source) | ✅ | Details related to where a payment originated | | `goodsType` | `string` | ✅ | Type of goods being purchased
**Values:** `PHYSICAL` (tangible items), `DIGITAL` (non-physical items), `MIXED` (combination of both) | | `productItems` | `array` of [ProductItem](/api-reference/objects/product-item) | ❌ | List of product or service items included in this payment | | `captureNow` | `boolean` | ❌ | Determines how the payment is processed
**Behavior:** `false` (default) - Authorization only, `true` - Sale (authorize and capture in one step) | | `descriptor` | `string` | ❌ | Text shown on the customer's bank statement (e.g., merchant or product name) | | `consumer` | [Consumer](/api-reference/objects/consumer) | ❌ | Consumer details such as name, email, phone | | `billing` | [Billing](/api-reference/objects/billing) | ❌ | Billing address information | | `shipping` | [Shipping](/api-reference/objects/shipping) | ⚠️ | Shipping address and recipient details. **Required when `goodsType` is not `"DIGITAL"`** | | `previousFailures` | `array` of [PreviousFailure](/api-reference/objects/previous-failure) | ❌ | Array of previous failed payment attempts with other providers. **Providing this context can help improve approval rates when retrying payments** | # PaymentMethod Source: https://docs.paymend.com/api-reference/objects/payment-method Payment method details for processing payments The `PaymentMethod` object defines how the customer wants to pay. ## Properties Request | Field | Type | Required | Description | | | :- | :- | :-: | :- | - | | `type` | `string` | ✅ | Type of payment method
**Supported Types:** `CARD` | `ENCRYPTED_CARD` - Credit or debit card | | `card` | [Card](/api-reference/objects/card) | ⚠️ | Card details. **Required when type is `"CARD"`** | | | `encryptedCard` | [Encrypted card](/api-reference/objects/encrpyted-card) | ⚠️ | Encrypted card details. **Required when type is `"ENCRYPTED_CARD"`** | | Response | Field | Type | Required | Description | | | :- | :- | :-: | :- | - | | `type` | `string` | ✅ | Type of payment method
**Supported Types:** `CARD` | `ENCRYPTED_CARD` - Credit or debit card | | `card` | [Card](/api-reference/objects/card-response) | ⚠️ | Card details. **Required when type is `"CARD"`** | | | `encryptedCard` | [Encrypted card](/api-reference/objects/encrpyted-card-response) | ⚠️ | Encrypted card details. **Required when type is `"ENCRYPTED_CARD"`** | | Additional payment methods (digital wallets, bank transfers, etc.) will be available in future updates. # PaymentResponse Source: https://docs.paymend.com/api-reference/objects/payment-response Unified response object returned after payment, refund, or void operations The `PaymentResponse` object contains the result of any payment operation (payment, refund, or void), including the payment status, transaction history, and any relevant details such as consumer, billing, shipping, product items, and payment method information. This unified model is used across all payment-related endpoints. ## Properties | Field | Type | Description | | :- | :- | :- | | `paymentId` | `string` | Unique identifier for the payment generated by the system (up to 32 char.) | | `merchantReference` | `string` | Reference passed in by the merchant for correlation | | `amount` | `integer` | Amount processed in the smallest currency unit | | `currency` | `string` | ISO 4217 currency code used in the payment | | `status` | `string` | Current state of the payment. See [Statuses](/api-reference/introduction#statuses) for detailed descriptions of each status value. For refunds, this will be "REFUNDED"; for voids, this will be "VOIDED" | | `failure` | `object` | Details about the cause of a failed payment (only present if status is FAILED) | | `paymentMethod` | `object` | The chosen payment method details (e.g., card) | | `captureNow` | `boolean` | Determines how the payment is processed. Default: false → Authorization only (funds reserved, must capture later). If true → Sale (authorize and capture in one step) | | `descriptor` | `string` | Text shown on the customer's bank statement (e.g., merchant or product name) | | `goodsType` | `string` | Type of goods being purchased: PHYSICAL = tangible items, DIGITAL = non-physical items, MIXED = combination of both | | `source` | `object` | Details related to where a payment originated | | `productItems` | `array` | List of product or service items included in this payment. Each item is a [ProductItem](/api-reference/objects/product-item) object | | `consumer` | `object` | Consumer details such as name, email, phone | | `billing` | `object` | Billing address information | | `shipping` | `object` | Shipping address and recipient details | | `transactions` | `array` of [Transaction](/api-reference/objects/transaction) | **Optional** array with details of all transactions processed for a payment. Provided when the payment is not in PENDING state. | | `createdAt` | `string` | Timestamp when the payment was created | | `updatedAt` | `string` | Timestamp when the payment was last updated | # PreviousFailure Source: https://docs.paymend.com/api-reference/objects/previous-failure Information about a previous failed payment attempt with another provider The `PreviousFailure` object represents information about a previous failed payment attempt with another payment provider. This allows merchants to provide context about failed attempts when retrying payments, which can help improve approval rates. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `provider` | `string` | ❌ | Name or identifier of the provider where the failure occurred. Contact your Account Manager for an enumerated list of possible values. | | `attemptNumber` | `integer` | ⚠️ | Sequential number of this attempt. At least one of attemptNumber or createdAt should be passed. | | `providerFailureCode` | `string` | ✅ | Provider-specific failure or decline code | | `createdAt` | `string` | ⚠️ | When the failure occurred (ISO 8601 date-time format). At least one of attemptNumber or createdAt should be passed. | ## Example ```json theme={null} { "provider": "AcquirerX", "attemptNumber": 1, "providerFailureCode": "05", "createdAt": "2025-11-05T14:22:10Z" } ``` # ProductItem Source: https://docs.paymend.com/api-reference/objects/product-item Represents a single product or service item within a payment The `ProductItem` object represents a single product or service item included in a payment transaction. This allows merchants to provide detailed line-item information for better transaction tracking and reporting. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `id` | `string` | ✅ | Unique identifier of the product or service in the merchant's catalog | | `name` | `string` | ✅ | Name or description of the item | | `quantity` | `integer` | ✅ | Quantity of this item being purchased (minimum: 1) | | `unitPrice` | `integer` | ✅ | Unit price in the smallest currency unit (e.g., cents for USD) (minimum: 1) | | `goodsType` | `string` | ✅ | Type of item
**Values:** `PHYSICAL` (tangible items), `DIGITAL` (non-physical items) | ## Example ```json theme={null} { "id": "PROD-001", "name": "Wireless Keyboard", "quantity": 2, "unitPrice": 1999, "goodsType": "PHYSICAL" } ``` # RefundRequest Source: https://docs.paymend.com/api-reference/objects/refund-request Request object for processing refunds The `RefundRequest` object is used to specify refund details when processing a refund. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `refundAmount` | `integer` | ❌ | Amount to refund in the smallest currency unit
**Notes:** Minimum value: 1, If omitted full refund is processed, Cannot exceed original captured amount | ## Usage **Full Refund**: Omit the `refundAmount` field to refund the entire captured amount. **Partial Refund**: Include `refundAmount` to refund a specific amount. ## Example - Full Refund ```json theme={null} {} ``` ## Example - Partial Refund ```json theme={null} { "refundAmount": 500 } ``` ## Business Rules * Refunds can only be processed on captured payments * Refund amount cannot exceed the captured amount * Multiple partial refunds are allowed until the full amount is refunded # Shipping Source: https://docs.paymend.com/api-reference/objects/shipping Shipping address and recipient information The `Shipping` object contains delivery information for physical goods. **Required when `goodsType` is not `"DIGITAL"`**, optional for digital goods. ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `address` | [Address](/api-reference/objects/address) | ❌ | Shipping address details | | `firstName` | `string` | ❌ | Recipient's first name | | `lastName` | `string` | ❌ | Recipient's last name | ## Usage Shipping information is used for: * **Physical goods delivery** - Where to ship the purchased items * **Fraud prevention** - Verifying shipping address matches customer * **Compliance** - Some regulations require shipping address verification * **Customer service** - Contact information for delivery issues Shipping information is typically required for `PHYSICAL` and `MIXED` goods and optional for `DIGITAL` goods. # Source Source: https://docs.paymend.com/api-reference/objects/source Details related to where a payment originated The `Source` object captures all details related to where a payment originated. For example: * Whether the payment was initiated by the consumer or the merchant * Identifying the store (e.g., website) where a payment originated * Details related to the device that was used to initiate the purchase ## Properties | Field | Type | Required | Description | | :- | :- | :-: | :- | | `storeId` | `string` | ✅ | A Paymend-defined identifier for the merchant's store (e.g. the website where the payment originated) | | `initiatedBy` | `string` | ❌ | Indicates who is initiating the payment, the `CONSUMER` or `MERCHANT`. | | `externalMerchantId` | `string` | ❌ | An externally-defined identifier for the merchant's legal entity (e.g. the LLC or corporation selling the goods/services) | ## Usage **Store** information is used for: * Risk & compliance purposes, ensuring we're only processing payments from recognized stores * Descriptor optimization, helping to reduce fraud rates Providing accurate **initiator** information helps improve payment success rates and fraud detection. # Transaction Source: https://docs.paymend.com/api-reference/objects/transaction Details about a transaction attempt made for a payment The `Transaction` object contains details about a single transaction attempt that was made for a payment. ## Properties | Field | Type | Description | | :- | :- | :- | | `id` | `string` | Unique identifier for the transaction generated by the system (up to 32 char.) | | `type` | `string` | The type of transaction that has been processed | | `amount` | `integer` | Amount processed in the smallest currency unit | | `result` | `string` | Whether the transaction attempt `SUCCEEDED` or `FAILED` | | `failure` | `object` | **Optional** object containing details about the cause of a failed transaction (only present if `result` is `FAILED`) | | `createdAt` | `string` | Timestamp when the payment was created | ## Example ```json theme={null} { "id": "AUTH_eUfZ9n3BCPJo", "type": "AUTH", "amount": "100", "result": "FAILED", "failure": { "failureCode": "INSUFFICIENT_FUNDS", "providerFailureCode": "51" }, "createdAt": "2025-12-15T10:22:10Z" } ``` # Core Concepts Source: https://docs.paymend.com/core-concepts The relationship between payments and transactions ## Payments and Transactions At the center of the API is the **[Payment](/api-reference/objects/payment)** entity. A payment represents the **intent to move funds**. That intent is fulfilled through one or more **[Transactions](/api-reference/objects/transaction)**. Each transaction is an **immutable record** of an operation attempted on the payment, such as authorization, capture, void, or refund. Transactions should be understood as **actions performed on a payment**. They describe what was attempted and the outcome of that attempt, but they never change once created. If a transaction fails, a new transaction must be created to attempt the same action again. The **Payment** acts as: * The **logical container** for all related **[transactions](/api-reference/objects/transaction)**. * The **lifecycle owner**, whose status is derived from the sequence and outcome of its transactions. A payment does not change state directly. Its status evolves **only when a transaction completes successfully**. If a transaction is attempted but does not succeed, the transaction is still recorded, but the **payment status remains unchanged**. For example, when attempt to refund a captured payment a new refund transaction is created and linked to the payment. The preceding capture transaction is unchanged. If that refund succeeds, the payment transitions to **Refunded**; if it fails, the payment remains **Captured**. A payment is composed of the following sub-entities: * **[Consumer](/api-reference/objects/consumer)** – The individual making the purchase. * **[Payment Method](/api-reference/objects/payment-method)** – The type and details of the method used to complete the payment (e.g., credit card, digital wallet). * **[Billing](/api-reference/objects/billing)** – The billing address and contact information associated with the payment method. * **[Shipping](/api-reference/objects/shipping)** – The delivery address and contact information for where the purchased items will be sent. * **[Product Items](/api-reference/objects/product-item)** – The individual products or services being purchased, including details such as name, quantity, unit price, and goods type. **Providing accurate product information increases the likelihood of payment approval**. * **[Previous Failures](/api-reference/objects/previous-failure)** – Information about previous failed payment attempts with other providers. **Providing this context can help improve approval rates when retrying payments**. * **[Transactions](/api-reference/objects/transaction)** – The immutable records of operations attempted on the payment, such as authorization, capture, void, or refund. ## Payment Lifecycle A payment moves through several statuses as it is processed. The diagram below shows the full state machine with the possible transitions across states: Payment Lifecycle ## Payment Statuses * **PENDING** – The payment has been created but not yet processed. This is a temporary status. * **AUTHORIZED** – Funds have been reserved in the consumer's account, but not yet captured. * **CAPTURED** – Funds have been debited from the consumer's account. * **VOIDED** – Funds reserved during authorization are unfrozen and available to the consumer again. This is a final status, a VOIDED payment can no longer be CAPTURED. * **REFUNDED** – Funds debited during capture are returned to the consumer. This is a final status, a refund cannot be reversed. * **FAILED** - The payment failed to be authorized. This is a final status, a new payment should be created to reattempt authorization. ## Key Notes After [creating a payment](/api-reference/endpoint/payment), the response status can be: * **PENDING** (only if asynchronous processing is enabled), or directly * **AUTHORIZED**, **CAPTURED**, or **FAILED** When a payment is **PENDING**, it may: * Transition to **AUTHORIZED** when funds are successfully reserved in the consumer's account by setting `captureNow=false`. * Transition directly to **CAPTURED** when funds have been debited from the consumer's account by setting `captureNow=true`. * Transition to **FAILED** if funds could not be authorized. **AUTHORIZED** payments can: * Transition to **CAPTURED** when funds are debited from the consumer's account. * Transition to **VOIDED** when reserved funds are unfrozen before capture. **CAPTURED** payments can: * Be **REFUNDED** when debited funds are returned to the consumer's account. **VOIDED** and **REFUNDED** both represent canceled payments. These are final states and cannot be reversed. **FAILED** is a final state, the payment cannot progress further. ## Transactions Types * **SALE** – Authorization and capture of funds in a single request. Initiated in payment creation when the `captureNow` flag is set as `true`. * **AUTH** – Authorization of funds with a separate capture request required to trigger movement of funds. Initiated in payment creation when the `captureNow` flag is set as `false`. * **CAPTURE** – Debiting of funds following successful authorization. Initiated by calling the `capture` endpoint. * **REFUND** – Return of captured funds to the consumer's account. Initiated by calling the `refund` endpoint. * **VOID** – Cancelation of authorized funds in the consumer's account. Initiated by calling the `void` endpoint. ## Key Notes A transaction represents a single operation performed against a payment that may change its state. Each transaction: * Is immutable once created * Has a specific type (see above) * Has a specific result: `SUCCEEDED` or `FAILED` * Represents what happened at a specific point in time Relationship with payments: * A payment in PENDING state may not have any transactions associated with it * Once processed, a payment can contain one or more transactions * Transactions are always associated with exactly one payment * The payment’s state is derived from the sequence and results of its transactions # Create payments Source: https://docs.paymend.com/create-payments Understand how to create a payment via Paymend Create a payment by submitting a `POST` request to [/v1/payments](/api-reference/endpoint/payment). ## Mandatory fields The basic data required to create a payment relates to: * The value of the payment: `amount` and `currency` * The payment method to be used: passed in the [PaymentMethod](/api-reference/objects/payment-method) object * Payment identifiers: * A merchant-defined unique identifier for the payment: `merchantReference` * A Paymend-defined unique identifier for the store where the payment originated (eg. website): `source.storeId` * The type of goods being purchased: `goodsType` ## Key fields In addition to the details noted above which must be provided, we highly recommend passing the following details in all requests: * Who initiated the payment: `source.initiatedBy` is a valuable card-on-file parameter and is mandatory to enable asynchronous processing * Consumer and billing data: passed in the [Consumer](/api-reference/objects/consumer) and [Billing](/api-reference/objects/billing) objects, respectively. These details increase the chances of approval and help with payment identification. * Determine the authorization type: use the `captureNow` field to actively determine whether funds are authorized and captured in a single or separate requests. If you're using Paymend for payment recovery, take a look at the [PreviousFailure](/api-reference/objects/previous-failure) object too. See our guide on payment recovery via Paymend [here](/recover-payments). ## Request Example payment creation request (authorize and capture in one step): ```json theme={null} { "amount": 12997, "currency": "USD", "merchantReference": "PAYMENT-12345", "goodsType": "MIXED", "captureNow": true, "source": { "storeId": "store_abc123", "initiatedBy": "CONSUMER" }, "paymentMethod": { "type": "CARD", "card": { "number": "4111111111111111", "holderName": "John Doe", "cvv": "123", "expiryMonth": "12", "expiryYear": "2030", "brand": "VISA" } }, "consumer": { "firstName": "John", "lastName": "Doe", "email": "john.doe@example.com" }, "billing": { "address": { "street": "123 Main Street", "city": "San Francisco", "state": "CA", "zip": "94105", "country": "US" } } } ``` ## Response Example success response (`200 OK`): ```json theme={null} { "paymentId": "pay_1234567890abcdef", "merchantReference": "PAYMENT-12345", "amount": 12997, "currency": "USD", "status": "CAPTURED", "goodsType": "MIXED", "captureNow": true, "source": { "storeId": "store_abc123", "initiatedBy": "CONSUMER" }, "paymentMethod": { "type": "CARD", "card": { "bin": "41111111", "last4": "1111", "holderName": "John Doe", "expiryMonth": "12", "expiryYear": "2030", "brand": "VISA" } }, "createdAt": "2024-01-15T10:30:00Z", "updatedAt": "2024-01-15T10:30:00Z", "transactions": [ { "id": "SALE_pU2HnmS8AcpI", "type": "SALE", "amount": 12997, "result": "SUCCEEDED", "createdAt": "2024-01-15T10:30:00Z" } ] } ``` # Manage payments Source: https://docs.paymend.com/manage-payments Understand how to manage payments via Paymend Here we'll look at how to manage payment states using the Paymend API: * **Capturing** authorized funds * **Refunding** captured payments * **Voiding** pending or authorized payments ## Captures Capture a payment by submitting a `POST` request to [`/v1/payments/{paymentId}/capture`](/api-reference/endpoint/capture). The `paymentId` received in the response to payment creation is passed as a path parameter. Partial captures are not yet supported. No body should be sent in the request. ## Refunds Refund a payment by submitting a `POST` request to [`/v1/payments/{paymentId}/refund`](/api-reference/endpoint/refund). The `paymentId` received in the response to payment creation is passed as a path parameter. If you wish to make a partial refund, the `refundAmount` should be passed in the request body. ## Voids Void a payment by submitting a `POST` request to [`/v1/payments/{paymentId}/void`](/api-reference/endpoint/void). The `paymentId` received in the response to payment creation is passed as a path parameter. ## Query Get payment details including the payment status by submitting a `GET` request to [`/v1/payments/{paymentId}`](/api-reference/endpoint/payment-details). The `paymentId` received in the response to payment creation is passed as a path parameter. # Recover payments Source: https://docs.paymend.com/recover-payments Your best practice guide to payment recovery via Paymend Paymend specializes in recovery of payments that have already failed authorization. Whether a payment is consumer or merchant-initiated, one-time or recurring: when you receive a decline from your primary payment provider, simply re-route it to Paymend and we’ll take care of the rest. It is not always possible to recover a failed payment immediately. In these cases, merchants can safely leave the payment with Paymend, confident that it will be handled by a platform designed to maximize the chance of eventual approval. Our recovery engine evaluates each failed payment using a rich set of signals and dynamically selects the optimal recovery strategy. In certain scenarios, this means intentionally waiting before attempting the payment again. A common example is an insufficient funds decline: retrying immediately is unlikely to succeed, so Paymend schedules a retry for when we expect the cardholder to have available balance again. ## Pending payments When Paymend requires additional time to process a payment, we respond to the payment creation request with a `PENDING` status. A `PENDING` status means: * The payment has been successfully created * No final authorization decision has been made yet * Paymend is actively managing recovery attempts `PENDING` is always a temporary state. Without any further action from the merchant, the payment will eventually transition to one of the following final statuses: * `AUTHORIZED` * `CAPTURED` * `FAILED` Paymend will never hold a payment in a non-terminal state indefinitely: we enforce a maximum recovery window of 30 days for all payments. If recovery is not successful within this window, the payment is marked as `FAILED` and no further attempts are made. You can see the lifecycle for payments with Paymend [here](/core-concepts). ## Best practices for `PENDING` payments While a payment is in `PENDING` state with Paymend, merchants may continue to attempt recovery outside of Paymend. To avoid conflicts or double charges, please follow these rules: 1. **Do not retry the same payment via Paymend while it remains in `PENDING` state**. 2. If circumstances change such that no further authorization attempts should be made for a `PENDING` payment (for example, the order is canceled or the consumer is successfully charged elsewhere), **the payment with Paymend must be [voided](/manage-payments#voids) to prevent a double charge**. In the event of a race condition where Paymend has already recovered the payment, resulting in a temporary double charge, you must issue a refund. Void a PENDING payment ## Webhooks Merchants should rely on Paymend webhooks to receive real-time notifications when a payment’s status changes (for example, when a payment moves from `PENDING` to `AUTHORIZED`). This avoids the need to poll the query endpoint for updates. You can find more details on Paymend webhooks [here](/webhooks). Payment status update via webhook ## Previous failure details The more information you can provide about previous attempts to process a payment, the more effectively Paymend can recover it. Paymend supports a [PreviousFailure](/api-reference/objects/previous-failure) object that allows you to pass details about earlier attempts and their failure reasons. This information helps route the payment onto the most effective recovery path more quickly. ## Integration checklist To ensure your integration to Paymend is of the highest quality, ensure that you: * Subscribe to webhooks (link to webhooks docs) * Handle `PENDING` as a non-terminal state * Void `PENDING` payments if no further authorization attempts should be made * Provide [PreviousFailure](/api-reference/objects/previous-failure) data where available # Reporting Source: https://docs.paymend.com/reporting Period-based reports covering payment creation, processing, disputes and settlement. Paymend makes processing and settlement detail available across four different reports, which collectively describe the full lifecycle of a payment, from the moment it is created through to the money settling in your account. Every payment record opened, whether or not it was later processed. Sales captured and refunds returned. Alerts, RDRs, chargebacks and fraud reports raised against your payments. Every event that contributed to a payout, with associated fees. ## Reports are period-based and immutable Each report covers one closed period. It is generated after the period ends and never changes afterwards. Regenerating a report for a period you already hold returns byte-identical content. If a report you already downloaded differs from a later copy, treat that as a defect and contact support rather than reconciling against it. This has two consequences worth designing around: * **A report is a safe primary key source.** Once you have ingested a period, you never need to re-read it to pick up amendments. * **Late-arriving data lands in a later period, not a restated one.** A dispute raised in September against a payment created in July appears in the September dispute report. It does not cause July's report to change. Every row in every report carries an `event_id` that is unique to that event. This is the event-level join key between processing and settlement reports. Non-payment events also have a `payment_id` - the same `paymentId` value returned in responses from the payments API - which allows reconciliation between an event and the payment that it relates to. ## File naming ``` {report_type}-{merchant_name}-{period_start}_to_{period_end}.csv ``` Dates are `YYYYMMDD`, and both bounds are inclusive. | Report | Example filename | | - | - | | Payments created | `report_payments_created-my_merchant-20260801_to_20260831.csv` | | Transactions succeeded | `report_transactions_succeeded-my_merchant-20260801_to_20260831.csv` | | Payments disputed | `report_payments_disputed-my_merchant-20260801_to_20260831.csv` | | Settlement paid out | `report_settlement_paid_out-my_merchant-20260912.csv` | **Settlement reports carry a single date, not a range.** That date is the payout date, not the period the report covers. The events inside it fall in the settlement period that closed before the payout ran — which depends on your payout schedule. `merchant_name` is your merchant identifier as configured on your Paymend account. It is stable and safe to parse. ## Which timestamp defines the period Each report is bounded on its own event timestamp, so the same payment can appear in reports covering different periods. | Report | Period column | Meaning | | - | - | - | | Payments created | `event_created_at` | When the payment record was created | | Transactions succeeded | `event_processed_at` | When the transaction was processed | | Payments disputed | `event_created_at` | When Paymend recorded the dispute event | | Settlement paid out | `event_effective_at` | When effective date for settlement, determining the period the event falls into | A payment created in June, captured in July and charged back in August appears in three different processing reports, each in the period matching that stage. ## Amounts and currency All amounts are decimal strings in major units — `97.00`, not `9700`. Negative values are debits against your payout. Each report states its own currency column; see the individual pages. ## Next steps How to join the four reports and prove that every processed event was paid out. # Payments created Source: https://docs.paymend.com/reporting/payments_created Every payment record created during the period. One row per payment record created, regardless of whether it was later processed, declined or canceled. This is the widest of the four reports and the starting point of the reconciliation chain. ``` report_payments_created-{merchant_name}-{period_start}_to_{period_end}.csv ``` Bounded on `event_created_at`. ## Columns | Column | Type | Description | | - | - | - | | `event_id` | string | Unique identifier for the payment. Used as `payment_id` in every other report. | | `event_created_at` | timestamp | When the payment record was created. UTC, microsecond precision. | | `event_type` | enum | Always `PAYMENT_CREATION`. | | `merchant_name` | string | Your merchant identifier. | | `store_id` | string | Store the payment belongs to, or `NA` where not configured. | | `merchant_reference` | string | Your own reference, as supplied on the payment request. Empty when not provided. | | `event_amount` | decimal | Payment amount in major units. | | `currency` | string | ISO 4217 currency of the payment. | | `consumer_first_name` | string | Consumer given name. | | `consumer_last_name` | string | Consumer family name. | | `consumer_email` | string | Consumer email address. | | `card_brand` | enum | `VISA`, `MASTERCARD`, `AMEX`, `DISCOVER`. | | `card_bin` | string | First 6-8 digits of the card number. | | `card_last_4_digits` | string | Last four digits of the card number. | `event_id` here is the payment identifier. It appears as `payment_id` — not as `event_id` — in the transactions, disputes and settlement reports. Every other report uses `event_id` for its own event, not for the payment. ## Creation does not imply processing A row in this report means a payment record exists. It does not mean money moved. A payment may be created and never processed, processed days later, or processed across several attempts. Expect this report to contain more rows than the transactions report for the same period, and do not treat the difference as a reconciliation break. See the [reconciliation guide](/reporting/reconciliation) for how to age unprocessed payments correctly. ## Example ```csv report_payments_created-my_merchant-20260801_to_20260810.csv theme={null} event_id,event_created_at,event_type,merchant_name,store_id,merchant_reference,event_amount,currency,consumer_first_name,consumer_last_name,consumer_email,card_brand,card_bin,card_last_4_digits PAYM_7bQ2xKmR4v,2026-08-01 09:14:02.000000 UTC,PAYMENT_CREATION,my_merchant,store_abc,ORD-88213,49.00,USD,Priya,Raman,priya.raman@example.com,VISA,411111,4242 PAYM_Nc9wTdLs3E,2026-08-01 11:47:55.000000 UTC,PAYMENT_CREATION,my_merchant,store_123,ORD-88214,129.50,USD,Tomas,Lindqvist,t.lindqvist@example.com,MASTERCARD,555555,8081 PAYM_Hj4zVpQa8M,2026-08-02 16:02:19.000000 UTC,PAYMENT_CREATION,my_merchant,store_abc,,49.00,USD,Awa,Diallo,awa.diallo@example.com,VISA,400005,1907 PAYM_Ry6kBnXu2W,2026-08-03 03:31:40.000000 UTC,PAYMENT_CREATION,my_merchant,store_123,ORD-88219,24.95,USD,Hannah,Byrne,hbyrne@example.com,AMEX,371449,6003 ``` # Payments disputed Source: https://docs.paymend.com/reporting/payments_disputed Alerts, RDRs, chargebacks and fraud reports raised against your payments. One row per dispute event recorded during the period. A dispute event is a signal received from a consumer or their issuing bank card scheme, via the acquirer, card scheme or a fraud prevention provider, which has been matched to one of your payments. ``` report_payments_disputed-{merchant_name}-{period_start}_to_{period_end}.csv ``` Bounded on `event_created_at` — when Paymend recorded the event, not when the underlying payment was posted. ## Event types | `event_type` | `event_program` | What it is | | - | - | - | | `ALERT` | `ETHOCA` | Ethoca alert — the issuer has flagged the transaction, giving a window to refund before it becomes a chargeback. | | `ALERT` | `VERIFI_CDRN` | Verifi CDRN alert, same purpose via a different network. | | `RDR` | `VERIFI_RDR` | Rapid Dispute Resolution — the dispute was resolved automatically by Verifi. Funds are credited to the consumer. | | `CHARGEBACK` | *(empty)* | A chargeback was raised. Funds are credited to the consumer. | | `FRAUD_REPORT` | `TC40` | A TC40 fraud report was filed by the issuer. | ## Columns | Column | Type | Description | | - | - | - | | `event_id` | string | Unique identifier for this dispute event. Joins to the settlement report. | | `event_created_at` | timestamp | When Paymend recorded the event. UTC. | | `payment_id` | string | The disputed payment. Matches `event_id` in the payments created report. | | `payment_created_at` | timestamp | When the disputed payment was originally processed. | | `merchant_name` | string | Your merchant identifier. | | `store_id` | string | Store the payment belongs to. | | `merchant_reference` | string | Your own reference from the payment request. | | `authorization_code` | string | Authorization code of the disputed payment, populated when available. | | `acquirer_reference_number` | string | ARN of the disputed payment, populated when available. | | `payment_amount` | decimal | Original payment amount, in major units. | | `payment_currency` | string | Currency of the original payment. | | `payment_descriptor` | string | Billing descriptor presented to the consumer. | | `consumer_first_name` | string | Consumer given name. | | `consumer_last_name` | string | Consumer family name. | | `consumer_email` | string | Consumer email address. | | `card_brand` | enum | Card brand of the disputed payment. | | `card_bin` | string | First 6-8 digits of the card number. | | `card_last_4_digits` | string | Last four digits of the card number. | | `event_type` | enum | `ALERT`, `RDR`, `CHARGEBACK`, `FRAUD_REPORT`. | | `event_status` | enum | Outcome of the event — see below. | | `event_amount` | decimal | Amount the scheme reported for the event. May differ from `payment_amount`. | | `event_currency` | string | Currency the scheme reported the event in. May differ from `payment_currency`. | | `event_scheme` | enum | Scheme that raised the event: `VISA`, `MASTERCARD`, `AMEX`, `DISCOVER`. | | `event_program` | enum | Prevention network, per the table above. | | `event_reason_code` | string | Scheme reason code, where supplied. | | `event_reason_code_description` | string | Human-readable form of the reason code, where supplied. | ### Event status | Value | Meaning | | - | - | | `REFUNDED` | The payment was refunded in response to the event. | | `VOIDED` | The payment was voided before capture. | | `NO_ACTION_TAKEN` | The event was recorded but no action was taken on the payment. | | `RESOLVED` | The dispute reached a terminal state. | ## One row per dispute event, not per payment A single payment can attract several dispute events — an Ethoca alert, then a TC40 report, then a chargeback. Each is a separate row with its own `event_id` and its own fee. ## Reason code coverage `event_reason_code` and `event_reason_code_description` are populated only where the scheme supplies them, and coverage varies by program. Build downstream logic to tolerate both fields being empty. ## Example ```csv report_payments_disputed-my_merchant-20260801_to_20260831.csv theme={null} event_id,event_created_at,payment_id,payment_created_at,merchant_name,store_id,merchant_reference,authorization_code,acquirer_reference_number,payment_amount,payment_currency,payment_descriptor,consumer_first_name,consumer_last_name,consumer_email,card_brand,card_bin,card_last_4_digits,event_type,event_status,event_amount,event_currency,event_scheme,event_program,event_reason_code,event_reason_code_description FRAD_9tRm2xQwLe,2026-08-03 02:11:07.412900 UTC,PAYM_7bQ2xKmR4v,2026-08-01 09:15:44 UTC,my_merchant,store_abc,ORD-88213,4419CD,74921500219000012345678,49.00,USD,8005550111acmewell,Priya,Raman,priya.raman@example.com,VISA,411111,4242,ALERT,REFUNDED,49.00,USD,VISA,ETHOCA,,FRAUD FRAD_Xv2pQs5Bn8,2026-08-11 18:44:22.008145 UTC,PAYM_Nc9wTdLs3E,2026-08-01 11:49:03 UTC,my_merchant,store_123,ORD-88214,90210B,74921500219000012345679,129.50,USD,8005550111acmewell,Tomas,Lindqvist,t.lindqvist@example.com,MASTERCARD,555555,8081,CHARGEBACK,RESOLVED,129.50,USD,MASTERCARD,,4853,Cardholder dispute FRAD_Wq3sHc7jTa,2026-08-14 05:09:31.663201 UTC,PAYM_Hj4zVpQa8M,2026-08-02 16:03:02 UTC,my_merchant,store_abc,,71204A,74921500219000012345680,49.00,USD,8005550111acmewell,Awa,Diallo,awa.diallo@example.com,VISA,400005,1907,RDR,RESOLVED,49.00,USD,VISA,VERIFI_RDR,10.4,Other fraud - card absent FRAD_Lm5bNe0kUr,2026-08-22 23:57:14.220847 UTC,PAYM_Ry6kBnXu2W,2026-08-03 03:32:15 UTC,my_merchant,store_123,ORD-88219,55120E,,24.95,USD,8005550111acmewell,Hannah,Byrne,hbyrne@example.com,AMEX,371449,6003,FRAUD_REPORT,NO_ACTION_TAKEN,24.95,USD,AMEX,TC40,,Fraudulent transaction ``` # Reconciliation guide Source: https://docs.paymend.com/reporting/reconciliation Join the four reports and prove every processed event was paid out. The four reports form a chain. Each stage is joined to the next by an identifier that both files carry. ``` payments_created ──payment_id──▶ transactions_succeeded ──event_id──▶ settlement_paid_out │ ▲ └────────────payment_id──▶ payments_disputed ──event_id────────────────┘ ``` ## Join keys | From | To | Key | | - | - | - | | Payments created | Transactions succeeded | `payments_created.event_id = transactions_succeeded.payment_id` | | Payments created | Payments disputed | `payments_created.event_id = payments_disputed.payment_id` | | Transactions succeeded | Settlement paid out | `event_id = event_id` | | Payments disputed | Settlement paid out | `event_id = event_id` | The final two joins are on `event_id` in both files. `event_id` is globally unique and never reused, so no composite key is needed and no type or period qualifier is required. ## Reconciling settlement Every row in a settlement report matches exactly one row in a transactions or disputes report. The relationship is one-to-one in both directions: no settlement row exists without a corresponding processed event, and within a settled period no processed event is missing from settlement. Take the transactions and disputes reports whose periods overlap the settlement period, and union their `event_id` values. Left join the settlement file's `event_id` against that set. Expect a complete match on both sides. Sum `event_amount` for `SALE` rows in the settlement file and compare with the transactions report. They tie exactly. Remember that refunds are signed negative in settlement and unsigned in transactions. Confirm the five component columns sum to `payout_amount`. Any row failing this indicates a corrupted file — re-download before investigating further. ### Period alignment A settlement report covers events whose `event_effective_at` falls within the settlement period. `event_effective_at` equals the date of the underlying event, so a transaction processed on 14 August settles in the period containing 14 August. Settlement periods follow your payout schedule, which may not be calendar months. Where your schedule is more frequent than monthly, one calendar month of transactions spans multiple settlement reports. ## Reconciling creation against processing Unlike settlement, this relationship is **not** one-to-one and is not expected to be. * A created payment may never be processed, so it appears in the creation report and nowhere else. * A created payment may be processed in a later period, so the two rows sit in reports covering different periods. * One payment may produce several transaction rows (e.g., a sale and one or more refunds). ## Reconciling disputes against payments Dispute events are frequently raised months after the payment was processed. The disputes report for August will contain events against payments created in June, March, or earlier. Never expect the disputes report for a period to join only to payments from the same period. Join on `payment_id` across your full payment history, and where a dispute references a payment you do not hold, extend the range of creation reports you have ingested rather than treating it as an orphan. The reverse direction also fails by design: a payment disputed in September will not appear in any August dispute report, even though the payment itself was processed in August. Dispute coverage is bounded by when the event was recorded, not when the payment was processed. ## Worked example Tracing payment `PAYM_123` across all four reports. ```report 1: payments_created theme={null} event_id,event_created_at,event_type,event_amount,currency,... PAYM_123,2026-08-01 09:14:02.000000 UTC,PAYMENT_CREATION,49.00,USD,... ``` ```report 2: transactions_succeeded theme={null} event_id,event_processed_at,event_type,payment_id,event_amount,... SALE_456,2026-08-01 09:15:44 UTC,SALE,PAYM_123,49.00,... REFN_789,2026-08-04 14:22:10 UTC,REFUND,PAYM_123,49.00,... ``` ```report 3: payments_disputed theme={null} event_id,event_created_at,payment_id,event_type,event_status,event_amount,... FRAD_999,2026-08-03 02:11:07.412900 UTC,PAYM_123,ALERT,REFUNDED,49.00,... ``` ```report 4: settlement_paid_out theme={null} event_id,event_effective_at,payment_id,event_type,event_amount,... SALE_456,2026-08-01,PAYM_123,SALE,49.00,... FRAD_999,2026-08-03,PAYM_123,ALERT,0,... REFN_789,2026-08-04,PAYM_123,REFUND,-49.00,... ``` The payment was created and captured on 1 August, flagged by an Ethoca alert on 3 August, and refunded on 4 August in response to that alert. All three events settle in the same period. ## Common pitfalls A refund's `payment_id` is the original payment, not the refund. Two refunds against one payment share a `payment_id`. Join on `event_id` to keep rows distinct. One payment can attract multiple fraud events. Grouping by `payment_id` collapses them and understates dispute fees. Aggregate on `event_id`. The date in a settlement filename is the payout date. The events inside it fall in the preceding settlement period. Use `event_effective_at` but note that in the case of settlement being delayed (e.g. while under Risk review), the pay-out may include events from a previous period. Fees are already negative. Subtracting them inverts the sign and doubles the error. Add all five component columns. Created payments may never be processed, or may process in a later period. Age unmatched rows across several periods before treating them as a break. # Settlement paid out Source: https://docs.paymend.com/reporting/settlement_paid_out Every event that contributed to a payout, with associated fees. One row per event included in a payout, covering both money movement and fees. The sum of `payout_amount` across the file is the amount paid to your account on the payout date. ``` report_settlement_paid_out-{merchant_name}-{payout_date}.csv ``` The single date in the filename is the **payout date**, not the period covered. A file named `...-20260912.csv` contains events with `event_effective_at` falling in the settlement period that closed before 12 September. ## Columns | Column | Type | Description | | - | - | - | | `event_id` | string | The event being settled. Matches `event_id` in the transactions or disputes report. | | `event_effective_at` | timestamp | When the event is eligible for payout. UTC. | | `payout_date` | date | When the event is paid out. | | `payment_id` | string | The payment the event relates to. | | `merchant_name` | string | Your merchant identifier. | | `store_id` | string | Store the payment belongs to. | | `merchant_reference` | string | Your own reference from the payment request. | | `event_type` | enum | `AUTH`, `CAPTURE`, `SALE`, `REFUND`, `ALERT`, `RDR`, `CHARGEBACK`, `FRAUD_REPORT`. | | `event_status` | enum | `AUTHORIZED`, `CAPTURED`, `REFUNDED`, `VOIDED`, `RESOLVED`, `NO_ACTION_TAKEN`. | | `event_amount` | decimal | Signed amount of the event itself. | | `event_currency` | string | Currency the event was denominated in, or `NA` where the event carries no amount. | | `payout_currency` | string | Currency this row is settled in. | | `fx_rate` | decimal | Rate applied to convert `event_amount` into `payout_currency`. Empty where no conversion applies. | | `platform_fee` | decimal | Variable processing fee. Negative when funds are deducted from the payout. | | `recovery_fee` | decimal | Fixed per-transaction fee. Negative when funds are deducted from the payout. | | `dispute_fee` | decimal | Fee charged for a dispute event. Negative when funds are deducted from the payout. | | `delayed_settlement_amount` | decimal | Amount to be paid out on longer settlement timeline. Negative. | | `payout_amount` | decimal | Net contribution of this row to the payout. | ## Every row sums The five component columns add up to `payout_amount` on every row, with no exceptions: ``` payout_amount = event_amount + platform_fee + recovery_fee + dispute_fee + delayed_settlement_amount ``` Debits are negative and credits positive, so the total is a plain sum — you never need to know which columns to subtract. This means signs differ between reports by design. A refund of 97.00 appears as `97.00` in the transactions report, where the amount is unsigned and direction comes from `event_type`, and as `-97.00` here, where the column feeds an arithmetic total. Summing `payout_amount` across the whole file gives the amount credited to your bank account on the payout date. ## What each event type contributes | `event_type` | `event_amount` | Fees applied | | - | - | - | | `AUTH` | Negative — amount debited | `recovery_fee` | | `SALE` | Positive — amount credited | `platform_fee`, `recovery_fee`, `delayed_settlement_amount` | | `CAPTURE` | Positive — amount credited | `platform_fee`, `recovery_fee`, `delayed_settlement_amount` | | `REFUND` | Negative — amount debited | `platform_fee`, `recovery_fee` | | `CHARGEBACK` | Negative — amount debited | `dispute_fee` | | `RDR` | Negative — amount debited | `dispute_fee` | | `ALERT` | Zero | `dispute_fee` | | `FRAUD_REPORT` | Zero | `dispute_fee` | `ALERT` and `FRAUD_REPORT` rows carry no amount because the event itself moves no money — they are notifications, and only the fee applies. Where an alert led you to refund the payment, that refund appears separately as its own `REFUND` row. ## Delayed settlement `delayed_settlement_amount` is a proportion of each capture withheld rather than paid out immediately. It is a hold, not a fee: the amount is returned on the agreed release schedule and appears as a separate release event in a later settlement report. Do not treat it as a cost when calculating your effective rate. ## Adjustments and corrections Occasionally we need to reverse or adjust an event after it has been settled, for example to correct an incorrect fee or amount. We follow standard accounting practice: finalised events are never edited or deleted. Instead, we post new events that correct the original, such as a reversal of the incorrect event followed by a corrected re-posting. Correcting events reuse the original `event_id` with a suffix: | Correction | Format | Example | | - | - | - | | Reversal | `{original_event_id}_REV_{n}` | `FRAD_xyz` → `FRAD_xyz_REV_1` | | Adjustment | `{original_event_id}_ADJ_{n}` | `REFN_xyz` → `REFN_xyz_ADJ_1` | `n` counts how many times that event has been reversed or adjusted, starting at 1. A second reversal of the same event would be `FRAD_xyz_REV_2`. A reversal flips the sign of every amount on the original row: `event_amount`, each fee column, `delayed_settlement_amount` and `payout_amount`. The original and its reversal therefore sum to zero, and the usual row identity still holds on the reversal row. This keeps every `event_id` unique across all report types, while letting you trace any correction back to the event it relates to by stripping the suffix. ## Example ### Settlement paid out ```csv report_settlement_paid_out-my_merchant-20260912.csv theme={null} event_id,event_effective_at,payout_date,payment_id,merchant_name,store_id,merchant_reference,event_type,event_status,event_amount,event_currency,payout_currency,fx_rate,platform_fee,recovery_fee,dispute_fee,delayed_settlement_amount,payout_amount AUTH_Qw7fRb2Nx4,2026-08-01 09:15:44 UTC,2026-09-01,PAYM_7bQ2xKmR4v,my_merchant,store_abc,ORD-88213,AUTH,AUTHORIZED,0,NA,USD,,0,-1.00,0,0,-1.00 SALE_Kv8dRn2Yx9,2026-08-01 11:49:03 UTC,2026-09-01,PAYM_Nc9wTdLs3E,my_merchant,store_123,ORD-88214,SALE,CAPTURED,129.50,USD,USD,1,-19.43,-1.00,0,-12.95,96.12 CAPT_Hm3yTv8Ld6,2026-08-02 10:04:11 UTC,2026-09-01,PAYM_7bQ2xKmR4v,my_merchant,store_abc,ORD-88213,CAPTURE,CAPTURED,49.00,USD,USD,1,-7.35,0,0,-4.90,36.75 FRAD_9tRm2xQwLe,2026-08-03 02:11:07 UTC,2026-09-01,PAYM_7bQ2xKmR4v,my_merchant,store_abc,ORD-88213,ALERT,REFUNDED,0,NA,USD,,0,0,-20.00,0,-20.00 REFN_Bd9nXq5Vh7,2026-08-03 14:22:10 UTC,2026-09-01,PAYM_7bQ2xKmR4v,my_merchant,store_abc,ORD-88213,REFUND,REFUNDED,-49.00,USD,USD,1,0,0,0,0,-49.00 SALE_Pj6cWz4Mt1,2026-08-07 08:33:52 UTC,2026-09-01,PAYM_Td5xGm9Kc3,my_merchant,store_123,ORD-88224,SALE,CAPTURED,250.00,USD,USD,1,-37.50,-1.00,0,-25.00,186.50 FRAD_Xv2pQs5Bn8,2026-08-11 18:44:22 UTC,2026-09-01,PAYM_Nc9wTdLs3E,my_merchant,store_123,ORD-88214,CHARGEBACK,RESOLVED,-129.50,USD,USD,1,0,0,-25.00,0,-154.50 FRAD_Lm5bNe0kUr,2026-08-22 23:57:14 UTC,2026-09-01,PAYM_Ry6kBnXu2W,my_merchant,store_123,ORD-88219,FRAUD_REPORT,NO_ACTION_TAKEN,0,NA,USD,,0,0,-15.00,0,-15.00 ``` ### Delayed settlement paid out ```csv report_settlement_paid_out-my_merchant-20260912.csv theme={null} event_id,event_effective_at,payout_date,payment_id,merchant_name,store_id,merchant_reference,event_type,event_status,event_amount,event_currency,payout_currency,fx_rate,platform_fee,recovery_fee,dispute_fee,delayed_settlement_amount,payout_amount SALE_Kv8dRn2Yx9,2026-08-01 11:49:03 UTC,2026-09-01,PAYM_Nc9wTdLs3E,my_merchant,store_123,ORD-88214,SALE,CAPTURED,0,USD,USD,1,0,0,0,12.95,12.95 CAPT_Hm3yTv8Ld6,2026-08-02 10:04:11 UTC,2026-09-01,PAYM_7bQ2xKmR4v,my_merchant,store_abc,ORD-88213,CAPTURE,CAPTURED,0,USD,USD,1,0,0,0,4.90,4.90 SALE_Pj6cWz4Mt1,2026-08-07 08:33:52 UTC,2026-09-01,PAYM_Td5xGm9Kc3,my_merchant,store_123,ORD-88224,SALE,CAPTURED,0,USD,USD,1,0,0,0,25.00,25.00 ``` # Transactions succeeded Source: https://docs.paymend.com/reporting/transactions_succeeded Successful transaction operations processed during the period. One row per successful transaction. Failed and declined attempts do not appear. ``` report_transactions_succeeded-{merchant_name}-{period_start}_to_{period_end}.csv ``` Bounded on `event_processed_at`. ## Columns | Column | Type | Description | | - | - | - | | `event_id` | string | Unique identifier for this transaction event. Joins to the settlement report. | | `event_processed_at` | timestamp | When the capture or refund completed. UTC. | | `event_type` | enum | `AUTH`, `CAPTURE`, `SALE`, `REFUND` or `VOID`. | | `payment_id` | string | The payment this transaction belongs to. Matches `event_id` in the payments created report. | | `merchant_name` | string | Your merchant identifier. | | `store_id` | string | Store the payment belongs to, or `NA` where not configured. | | `merchant_reference` | string | Your own reference from the payment request. | | `authorization_code` | string | Authorization code returned by the issuer. Empty if not available. | | `acquirer_reference_number` | string | ARN assigned by the acquirer. Empty if not available. | | `event_amount` | decimal | Amount in major units, always positive. See the sign note below. | | `currency` | string | ISO 4217 currency. | | `descriptor` | string | Billing descriptor presented to the consumer. | | `consumer_first_name` | string | Consumer given name. | | `consumer_last_name` | string | Consumer family name. | | `consumer_email` | string | Consumer email address. | | `card_brand` | enum | `VISA`, `MASTERCARD`, `AMEX`, `DISCOVER`. | | `card_bin` | string | First 6-8 digits of the card number. | | `card_last_4_digits` | string | Last four digits of the card number. | `event_amount` is unsigned in this report — a refund of 97.00 appears as `97.00`, not `-97.00`. Use `event_type` to determine direction. The settlement report signs the same amount negative, because there the column feeds an arithmetic total. ## Refunds Refunds need care, because two different identifiers are in play. * `payment_id` is the **original payment** being refunded, prefixed `PAYM_`. It is the same value that appears on the corresponding `SALE` or `CAPTURE` row. * `event_id` identifies the **refund itself**, prefixed `REFN_`. Do not join refunds to sales on `payment_id` alone and assume a one-to-one result. A single payment can be refunded more than once, and both refund rows will carry the same `payment_id`. Always carry `event_id` through as the row identity. The prefix tells you what a row is without reading `event_type`, but it is not a substitute for it — match on `event_type` in your logic and treat the identifier itself as opaque. ## Example ```csv report_transactions_succeeded-my_merchant-20260801_to_20260831.csv theme={null} event_id,event_processed_at,event_type,payment_id,merchant_name,store_id,merchant_reference,authorization_code,acquirer_reference_number,event_amount,currency,descriptor,consumer_first_name,consumer_last_name,consumer_email,card_brand,card_bin,card_last_4_digits AUTH_Qw7fRb2Nx4,2026-08-01 09:15:44 UTC,AUTH,PAYM_7bQ2xKmR4v,my_merchant,store_abc,ORD-88213,4419CD,74921500219000012345678,49.00,USD,8005550111acmewell,Priya,Raman,priya.raman@example.com,VISA,411111,4242 SALE_Kv8dRn2Yx9,2026-08-01 11:49:03 UTC,SALE,PAYM_Nc9wTdLs3E,my_merchant,store_123,ORD-88214,90210B,74921500219000012345679,129.50,USD,8005550111acmewell,Tomas,Lindqvist,t.lindqvist@example.com,MASTERCARD,555555,8081 CAPT_Hm3yTv8Ld6,2026-08-04 14:22:10 UTC,CAPTURE,PAYM_7bQ2xKmR4v,my_merchant,store_abc,ORD-88213,4419CD,,49.00,USD,8005550111acmewell,Priya,Raman,priya.raman@example.com,VISA,411111,4242 REFN_b7Kq2mXpLd,2026-08-09 07:05:51.114302 UTC,REFUND,PAYM_Ry6kBnXu2W,my_merchant,store_456,ORD-88219,55120E,,24.95,USD,8005550111acmewell,Hannah,Byrne,hbyrne@example.com,AMEX,371449,6003 ``` # Testing Source: https://docs.paymend.com/testing How to use the sandbox environment to develop and test your integration before going live We provide a testing environment that allows merchants and partners to validate their integration to the Paymend API without processing real payments. The sandbox is designed to validate: * Request structure and mandatory fields * Authentication handling * Core payment flows (create, capture, refund, void, query) * Basic success and failure scenarios * Asynchronous responses Responses are mocked and limited to predefined behaviors. When creating subsequent operations (capture, refund, void or query) the `id` value returned in the payment creation response should be referenced as a path parameter. ## API environments The following details should be used for testing your integration in sandbox: | Environment | Base URL | Notes | | - | - | - | | Sandbox | [https://api.sandbox.paymend.com](https://api.sandbox.paymend.com) | Use for testing only. Transactions are simulated. | **Important:** Always use your sandbox credentials when testing. Production credentials are separate and should be kept secure. ## Authentication All API requests require a **Bearer token** in the `Authorization` header: 👉 To get your API token, just reach out to your Paymend sales representative. ```http theme={null} Authorization: Bearer ``` * Tokens are issued specifically for sandbox use. * Requests without valid authentication will return 401 Unauthorized. * Ensure you are using sandbox credentials when targeting the sandbox environment. In the sandbox environment, the field `source.storeId` should be populated with `store_sandbox` ## Asynchronous payments Supporting asynchrous responses via Paymend is highly recommended to maximise recovery, and receiving payment status change notifications via webhook is the best way to stay updated. In sandbox, `PENDING` payments will resolve automatically. These will transition to `AUTHORIZED` or `CAPTURED` (per `captureNow`) after 30 minutes. This transition triggers the payment status update webhook. Webhooks can be setup in sandbox upon request. Please let your Paymend sales representative know that you would like these to be configured. ## Test cards Real card numbers should never be used in the sandbox environment. When creating payments in the sandbox, specific test card numbers determine simulated outcomes. ### `CARD` payment method type The table below shows which card number and brand values can be passed in the `paymentMethod` object during payment creation to receive different `status` and `failure` object values in the response. | `card.number` | `card.brand` | `status` | `failure.failureCode` | | - | - | - | - | | 444444444444**0000** | VISA | `AUTHORIZED` / `CAPTURED`\* | | | 555555555555**0000** | MASTERCARD | `AUTHORIZED` / `CAPTURED`\* | | | 444444444444**0051** | VISA | `FAILED` | `INSUFFICIENT_FUNDS` | | 555555555555**0051** | MASTERCARD | `FAILED` | `INSUFFICIENT_FUNDS` | | 444444444444**0099** | VISA | `PENDING` | | | 555555555555**0099** | MASTERCARD | `PENDING` | | \*Whether you receive `AUTHORIZED` or `CAPTURED` will depend on the value passed in the `captureNow` field. Any 3-4 digit value is accepted for `card.cvv`. ### `ENCRYPTED_CARD` payment method type The table below shows which encrypted card value and brand values can be passed in the `paymentMethod` object during payment creation to receive different `status` and `failure` object values in the response. | `encryptedCard.number` | `card.brand` | `status` | `failure.failureCode` | | - | - | - | - | | ev-testEncryptedPan44**0000** | VISA | `AUTHORIZED` / `CAPTURED`\* | | | ev-testEncryptedPan55**0000** | MASTERCARD | `AUTHORIZED` / `CAPTURED`\* | | | ev-testEncryptedPan44**0051** | VISA | `FAILED` | `INSUFFICIENT_FUNDS` | | ev-testEncryptedPan55**0051** | MASTERCARD | `FAILED` | `INSUFFICIENT_FUNDS` | | ev-testEncryptedPan44**0099** | VISA | `PENDING` | | | ev-testEncryptedPan55**0099** | MASTERCARD | `PENDING` | | \*Whether you receive `AUTHORIZED` or `CAPTURED` will depend on the value passed in the `captureNow` field. | `encryptedCard.number` | | - | | ev-testEncryptedCvv123 | ## Request examples You can find example requests for payment creation and payment management by following the links below: * [Create payments](/create-payments) * [Manage payments](/manage-payments) ## Next Steps Once your integration is working smoothly in sandbox: * Request production credentials from Paymend. * Update your base URL to the production endpoint. * Perform live transaction testing as needed. # Webhooks Source: https://docs.paymend.com/webhooks Stay up to date about payment status Paymend supports **webhooks** to notify you about changes in payment status. Webhooks provide a reliable, asynchronous mechanism to receive real-time updates about payments, helping you to automate reconciliation and customer notifications without the need for constant polling. We strongly encourage merchants to use webhooks as the primary method for tracking payment status, as they enable frictionless asynchronous processing. Our platform is designed to schedule retries in case immediate payment recovery is not possible. By enabling webhooks, you will benefit from the full spectrum of recovery options that Paymend offers. ## Webhook events Paymend webhooks notify you about payment status changes. Each webhook event includes details about the payment and its current status. | Event | Description | Payment status | | :-: | :- | :-: | | **PAYMENT\_CREATED** | The payment has been created but not yet processed. | `PENDING` | | **PAYMENT\_AUTHORIZED** | The payment has been successfully authorized, freezing funds in the consumer’s account. A capture request is required to debit the funds from the account. | `AUTHORIZED` | | **PAYMENT\_CAPTURED** | The payment has been successfully captured. Funds have been debited from the consumer’s account. | `CAPTURED` | | **PAYMENT\_REFUNDED** | The payment has been successfully refunded. Previously captured funds have been returned to the consumer’s account. | `REFUNDED` | | **PAYMENT\_VOIDED** | The payment has been successfully voided. Previously authorized funds have been unfrozen and are available to the consumer again. | `VOIDED` | | **PAYMENT\_FAILED** | The payment failed to be authorized. A new payment should be created to reattempt authorization. | `FAILED` | ## How to use webhooks with Paymend ### Endpoint requirements In order to receive webhooks from Paymend, you must provide a URL that Paymend can use for the delivery. The URL must use the **https** scheme, using either TLS 1.3 or 1.2 with a server certificate signed by a well-known certificate authority, which may include a custom path and query parameters. When an event occurs, Paymend will send a `POST` request to the configured URL. ### Responding to webhooks To acknowledge successful delivery of a webhook, you must respond with an HTTP “2xx” success status in less than 500ms. If your system needs more time to process an event, we recommend you store the payload for later access and acknowledge the webhook immediately. You may receive the same webhook event more than once (due to connectivity issues). The `eventId` field in the payload uniquely identifies each event. If you receive a webhook containing an `eventId` value that has already been processed, it can be ignored, however, even in this case you should still respond with an HTTP “2xx” success status to prevent further attempts. ### Retrying webhooks If Paymend is unable to reach the configured URL, does not receive a response in time, or receives an HTTP “5xx” server error or a “429 Too Many Requests” error, then delivery will be retried. For other HTTP “4xx” client errors, delivery will not be retried. Delivery will be retried shortly after an initial failure. If additional failures occur, then the interval between retries will increase exponentially (up to 1 hour between retries). This is meant to allow receivers more time to recover from potential issues, but can cause webhook delivery to take longer than usual. In any case, delivery will be cancelled if a maximum number of retries is exceeded. ### Verifying webhooks Every HTTP request from Paymend will contain an **Authorization** header using the **Bearer** authentication scheme. To guarantee that requests you receive are legitimate webhooks from Paymend, you must validate the bearer token and discard any request that does not match your merchant-specific webhook secret. ## Webhook payload ### Payment creation **PAYMENT\_CREATED** webhooks will always have a `PENDING` status. Each webhook will contain the following fields: | Field | Type | Description | | :- | :- | :- | | `eventId` | `string` | Webhook event unique id. Any events with an id that was already received can be considered a duplicate. | | `eventType` | `string` | The type of webhook event | | `version` | `string` | Webhook payload version | | `timestamp` | `string` | Timestamp when the webhook was created | | `data` | `object` | Object containing the [PaymentResponse](/api-reference/objects/payment-response) | Example **PAYMENT\_CREATED** webhook: ```json theme={null} { "eventId": "EVNT_1234567890abcdef", "eventType": "PAYMENT_CREATED", "version": "1.0", "timestamp": "2026-01-27T12:00:00Z", "data": { "paymentId": "pay_1234567890abcdef", "merchantReference": "ORDER-12345", "amount": 12997, "currency": "USD", "status": "PENDING", "paymentMethod": { "type": "CARD", "card": { "bin": "41111111", "holderName": "John Doe", "expiryMonth": "12", "expiryYear": "2025", "last4": "1111", "cvvPresentDuringAttempt": true, "brand": "VISA" } }, "captureNow": true, "descriptor": "MyStore Online", "goodsType": "MIXED", "productItems": [ { "id": "PROD-001", "name": "Wireless Keyboard", "quantity": 2, "unitPrice": 4999, "goodsType": "PHYSICAL" }, { "id": "PROD-002", "name": "E-Book Subscription", "quantity": 1, "unitPrice": 2999, "goodsType": "DIGITAL" } ], "consumer": { "firstName": "John", "email": "john.doe@example.com", "lastName": "Doe", "phone": "+1234567890", "ip": "192.168.1.1" }, "billing": { "address": { "street": "123 Main Street", "city": "San Francisco", "country": "US", "state": "CA", "zip": "94105" } }, "shipping": { "address": { "street": "123 Main Street", "city": "San Francisco", "country": "US", "state": "CA", "zip": "94105" }, "firstName": "Jane", "lastName": "Smith" }, "createdAt": "2024-01-15T10:30:00Z", "updatedAt": "2024-01-15T11:00:00Z" } } ``` ### Payment status update Webhooks related to changes in payment status will contain the following fields: | Field | Type | Description | | :- | :- | :- | | `eventId` | `string` | Webhook event unique id. Any events with an id that was already received can be considered a duplicate. | | `eventType` | `string` | The type of webhook event | | `version` | `string` | Webhook payload version | | `timestamp` | `string` | Timestamp when the webhook was created | | `data` | `object` | Object containing basic payment information | Example **PAYMENT\_AUTHORIZED** webhook: ```json theme={null} { "eventId": "EVNT_1234567890abcdef", "eventType": "PAYMENT_AUTHORIZED", "version": "1.0", "timestamp": "2026-01-27T12:00:00Z", "data": { "paymentId": "pay_1234567890abcdef", "merchantReference": "ORDER-12345", "amount": 12997, "currency": "USD", "status": "AUTHORIZED", "captureNow": true, "descriptor": "MyStore Online", "createdAt": "2024-01-15T10:30:00Z", "updatedAt": "2024-01-15T11:00:00Z", "links": { "capturePayment": "/api/v1/payments/pay_1234567890abcdef/capture", "voidPayment": "/api/v1/payments/pay_1234567890abcdef/void", "getPayment": "/api/v1/payments/pay_1234567890abcdef" } } } ``` # Welcome to the Paymend API Source: https://docs.paymend.com/welcome-to-the-paymend-api Explore our guides and documentation to integrate Paymend API. Welcome to the Paymend API ## The Paymend API We built the Paymend API with one thing in mind: **helping you create smooth and reliable payment experiences for your customers and actively recover revenue that would otherwise be lost to failed or declined transactions**.\ It’s simple to get started, yet flexible enough to grow with your business and support new features. Here’s what you can expect: * **Easy to use** – clear endpoints, predictable behavior. * **Built with care** – designed to evolve without breaking what already works. * **Future-friendly** – ready to support new flows and payment methods as they come. Our goal is to provide you an effortless payment integration to help you recover failed transactions and turn them into revenue. View the full API documentation ## Authentication All API requests require a **Bearer token** in the `Authorization` header: 👉 To get your API token, just reach out to your Paymend sales representative. ```http theme={null} Authorization: Bearer ``` ## API Environments Paymend provides two environments to safely build and test your integration, sandbox and production. | Environment | Base URL | Notes | | - | - | - | | Sandbox | [https://api.sandbox.paymend.com](https://api.sandbox.paymend.com) | Use for testing only. Transactions are simulated. | | Production | [https://api.prod.paymend.com](https://api.prod.paymend.com) | Live environment. Real transactions and data. | **Important:** Always use your sandbox credentials when testing. Production credentials are separate and should be kept secure. ## Support Need help? **We’re here for you.** Reach out to your Paymend sales representative for support. Whether you have questions about integration, troubleshooting or advanced features, don’t hesitate to get in touch. We love helping developers succeed! ## Security & Compliance At Paymend, protecting your business and your customers is at the heart of everything we do. Payments move sensitive information, and we make sure it’s handled with the highest level of security.
✅
PCI DSS Level 1
🔒
TLS Encryption
🛡️
Tokenization
🌍
GDPR Compliance
⚡
Fraud Protection
Here’s what you can count on: * **PCI DSS Compliance** – Cardholder data is processed exclusively through certified PCI infrastructure, ensuring the highest standard of data protection. * **Data encryption** – All data is encrypted in transit (TLS 1.2+) and at rest. * **Tokenization** – Sensitive payment details are never stored directly; we use tokenization to reduce your compliance burden. * **Privacy first** – We follow GDPR and other regional data protection requirements to safeguard your customers’ information. * **Fraud protection** – Built-in checks and integrations to help detect and prevent fraudulent activity. 👉 You don't need to be a security expert to use Paymend. We take care of the heavy lifting so you can focus on building smooth payment experiences.
Paymend LinkedIn