vonpay-checkout

Python SDK for the Von Payments Checkout API. Create hosted checkout sessions, verify webhook signatures, and validate signed return redirects.

Install

pip install vonpay-checkout

Requires: Python 3.9+, httpx 0.27+

Quick start

from vonpay.checkout import VonPayCheckout, VonPayError

client = VonPayCheckout("vp_sk_test_...")

session = client.sessions.create(
    amount=1499,
    currency="USD",
    country="US",
    success_url="https://example.com/order/123/confirm",
)

print(session.checkout_url)
# https://checkout.vonpay.com/checkout?session=vp_cs_test_...

Discrete-lifecycle API

The payment_intents, refunds, tokens, and capabilities namespaces give server-side control over payment intents, alongside the existing hosted-checkout sessions flow.

# Create a payment intent (auth + capture)
intent = client.payment_intents.create(
    amount=1499,
    currency="usd",
    capture_method="automatic",
    metadata={"order_id": "ord_42"},
    idempotency_key="ord_42-charge-1",
)
print(intent.id, intent.status)  # "vpi_live_…", "succeeded"

# Auth-only + later capture (fulfillment-on-ship)
auth = client.payment_intents.create(
    amount=1499, currency="usd", capture_method="manual", idempotency_key="ord_43-hold-1"
)
client.payment_intents.capture(auth.id, amount_to_capture=1499)

# Refund a captured intent (partial or full)
refund = client.refunds.create(payment_intent=intent.id, amount=500)

# Create a reusable token for save-card / MIT flows
token = client.tokens.create(buyer_id="buyer_42", setup_for_future_use="off_session")

# List a buyer's saved, active cards (newest first; page with next_cursor / has_more)
cards = client.payment_methods.list(buyer_id="buyer_42")

# A signed-in shopper removes their own card — PERMANENT. A repeat returns already_revoked=True.
client.tokens.revoke(cards.data[0].id, buyer_id="buyer_42", initiated_by="buyer")

# Read the merchant's processor capability matrix before invoking optional ops
caps = client.capabilities.get()
if caps.supported_operations.partial_refund:
    # partial refunds supported — safe to offer partial-refund UI
    ...

Send idempotency_key on every payment_intents.create. Use one value per charge and send the same value on every retry of that charge. A charge without one still works today, but from 28 October 2026 the API refuses it with 400 idempotency_key_required (nothing is charged), and this SDK emits a one-time FutureWarning until then. The key becomes required by this SDK in its next major version.

Migrating from 2.x

3.0.0 changes two behaviours. Nothing else in the 2.x API was removed or renamed.

1. payment_intents.void() is retried automatically only when you pass an idempotency key. After a timeout or a 500/502/503/504, 2.x retried a void on its own. 3.x does that only when the call carries a key, exactly as it already did for capture() and refunds.create(). Without one, the first error is raised with retry_withheld=True. To keep automatic retries:

   client.payment_intents.void(payment_intent_id, idempotency_key=f"{order_id}-void")
   

2. A redirect from the API is now its own error, unexpected_redirect. The API never redirects, and this SDK has never followed one. 3.x raises a VonPayError with code == "unexpected_redirect", retryable is False and next_action == "check_configuration" (2.x raised a generic error). If you see it, check your base_url (the API origin itself, https://checkout.vonpay.com: https, no path), any proxy, and your network. Do not retry it. If you branch exhaustively on err.next_action, add the new "check_configuration" value.

Features

• Typed session / webhook / error objects — full CheckoutSession, SessionStatus, WebhookEvent, VonPayError types.
• Webhook verification — webhooks.construct_event(raw_body, signature_header, signing_secret) parses the x-vonpay-signature: t=<unix>,v1=<hex> header, verifies HMAC-SHA256 over f"{t}.{raw_body}" keyed by your per-endpoint signing secret (whsec_…), and enforces the freshness window (≤5 min old / ≤30 sec future). Accepts multiple v1= entries for zero-downtime secret rotation.
• Test events — check event.test_event FIRST (2.7.0+). It is True only on an event synthesized by "Send test event"; livemode does not tell you this. Return 2xx and do nothing else — a test event can carry a real session's ids.
• Re-read a payment — payment_intents.retrieve(id) (2.7.0+) returns its stored state. On a 3-D Secure return page use it, with the id you stored at create time, instead of the URL's query params.
• Return confirmation — client.sessions.confirm_return(params, session_secret) verifies the signature and confirms server-side that the payment succeeded, returning ReturnOutcome(paid, signature_valid, status, reason). Use this, and branch on paid. ⛔ verify_return_signature() is DEPRECATED and STOPS WORKING on or after 2026-10-13 — the redirect stops carrying sig / status / amount / currency / transaction_id at all, so there will be nothing to verify and it will refuse every return. Migrate before that date. (It was also never usable as merchant-side proof: the signature uses a platform-wide secret no merchant was ever issued.) It proves a message is AUTHENTIC, and a declined payment is signed just as validly, so a true from it was never proof of payment either. ⚠️ reason == "still_pending" means the charge is in flight (the ordinary 3-D Secure case) — show a neutral "confirming your payment", never a failure. ⚠️ paid: true still does not mean safe to fulfil: record which session IDs you have already fulfilled, and prefer fulfilling from the charge.succeeded webhook. ⚠️ Not session.succeeded — that event is emitted internally but is not subscribable: it is absent from the merchant subscription catalog, which accepts an unknown event key, stores nothing and returns success. An endpoint subscribed to it receives nothing, forever, with no error raised at any layer. charge.succeeded is the fulfilment event.
• Auto-retry — exponential backoff on 429 / 5xx with Retry-After header support.
• Plugin identification — building a plugin other merchants install? Pass app_info={"name": ..., "version": ..., "url": ...} and it is appended to the User-Agent of every request.
• Request ID tracing — every response includes X-Request-Id for support tickets.

Documentation

• Python SDK reference
• API reference
• Quickstart

License

MIT