Capabilities

GET /v1/capabilities returns the effective capability matrix for the authenticated merchant: which payment-intent operations are supported, which settlement currencies are available, and the payment-intent rate limit. The matrix is processor-agnostic — it never identifies which underlying provider supplies a capability, so you branch on the capability, not on a processor name.

Read it once at integrator startup and cache it for the process lifetime. Branch on it before invoking optional operations (separate capture, partial refund, void-after-capture) so you fail early in your own code instead of round-tripping to a 501 from the API.

Authentication: any valid API key — both publishable (vp_pk_*) and secret (vp_sk_*) keys are accepted, since the matrix is read-only metadata. Available in SDK 0.5.0+.

Request

curl https://checkout.vonpay.com/v1/capabilities \
  -H "Authorization: Bearer vp_sk_test_YOUR_KEY"

const caps = await client.capabilities.get();

Response

{
  "supported_operations": {
    "auth_capture_separation": true,
    "partial_capture": true,
    "partial_refund": true,
    "unreferenced_refund": false,
    "void_after_capture": "rerouted_to_refund",
    "mit": true,
    "network_tokens": true,
    "three_d_secure_2": false,
    "ach": false,
    "payouts_api": false
  },
  "settlement_currencies": ["USD", "EUR", "GBP", "CAD", "AUD"],
  "rate_limits": {
    "payment_intents_per_minute": 100
  }
}

In the Node SDK the keys are camelCase (caps.supportedOperations.partialCapture); on the wire they are snake_case as shown above.

supported_operations

Flag	Type	Meaning
auth_capture_separation	boolean	Authorize and capture can be separate steps (capture_method: "manual" on the payment intent, then POST /v1/payment_intents/:id/capture).
partial_capture	boolean	Capture less than the authorized amount.
partial_refund	boolean	Refund less than the captured amount via POST /v1/refunds with an amount.
unreferenced_refund	boolean	Issue a refund that does not reference an original charge.
void_after_capture	string enum	supported — voiding a captured intent works. not_supported — it does not. rerouted_to_refund — a void on a captured intent is transparently handled through the refund pathway. See branching below.
mit	boolean	Merchant-initiated transactions (e.g. recurring, unscheduled).
network_tokens	boolean	Network tokenization is available for the merchant's processor.
three_d_secure_2	boolean	3-D Secure 2 is available.
ach	boolean	ACH bank-transfer payments.
payouts_api	boolean	Payouts API.

settlement_currencies

Array of ISO 4217 currency codes the merchant can settle in.

rate_limits

Field	Type	Meaning
payment_intents_per_minute	integer	Per-minute ceiling for POST /v1/payment_intents.

Branching on the matrix

Check the matrix before an optional operation instead of catching a 501:

const caps = await client.capabilities.get();

if (caps.supportedOperations.voidAfterCapture === "rerouted_to_refund") {
  // Voiding a captured intent goes through the refund pathway — call refunds.create.
  await client.refunds.create({ paymentIntent: pi.id });
} else if (caps.supportedOperations.voidAfterCapture === "supported") {
  await client.paymentIntents.void(pi.id);
}

An operation the active binder does not support returns 501 endpoint_not_implemented. An operation that is supported but invalid for the intent's current state returns 409 invalid_transition.

Related

• Payment Intents — the operations gated by this matrix
• Refunds — partial-refund and void-after-capture behavior
• Error Codes — endpoint_not_implemented, invalid_transition