Module and release scope
This guide covers Checkout.com Payment Links 1.0.0, Extension API 1, from the reviewed product source. Its declared core range is 1.3.6–1.3.99. Use the matching released core and signed provider package; a version label alone does not install the required contracts. Source availability does not mean the module is bundled in every currently downloadable product, installed on your server, enabled or certified for your merchant/server account. Nothing in this guide enables a provider or changes your existing connections.
Open System → Payment gateways (newer source may group these as Payments, Domain services or Hosting services). Install the reviewed signed package through Modules & addons or the integration workspace's Install tab, enable the module separately, add an account/connection, save its own credentials, run its stated Test and explicitly enable the connection. Saving or retesting disables the connection until you enable it again. Start with the provider's test environment where supported; otherwise use an isolated account or server.
Exact connection fields
These are the fields declared by this module. Secret values are entered privately and encrypted by the application. Defaults are configuration hints, not approved live merchant settings. Internal fields are populated by the module and are not operator-editable.
| Key / label | Type | Required | Default / guidance |
|---|---|---|---|
mode — Environment |
select | Yes | Default: "sandbox" Choices: sandbox = Sandbox, live = Live |
api_prefix — Account API prefix |
text | Yes | Enter only the account prefix shown in Checkout.com Dashboard → Developers → API keys, not an API URL. |
secret_key — Secret API key |
secret | Yes | A sandbox sk_sbox_ key or production sk_ key. Allow Payment Links, payment details and read-only workflows. |
processing_channel_id — Processing channel ID |
text | Yes | Use the account-specific value described below. |
webhook_secret — Webhook signing secret |
secret | Yes | The HMAC-SHA256 key configured on the payment_captured webhook action. |
accepted_currencies — Enabled invoice currencies |
text | Yes | Default: "USD" Comma-separated approved two-decimal currencies. No invoice currency conversion. |
Hosted one-off invoice checkout using Checkout.com's Payment Links API. Requires EmailaBiller 1.3.6 or later. Installed disabled, with no business configuration or credentials.
Configure
- Complete Checkout.com onboarding and enable Payment Links, card/wallet methods, processing channels and currencies approved for your entity.
- In Dashboard → Developers → API keys, copy the account API prefix and a scoped secret key (
sk_sbox_…for Sandbox;sk_…for Live). Enter only the prefix, not a URL. Enable Payment Links, payment details and read-only Workflows access. OAuth credentials are not used by this module. - Copy the exact
pc_…processing channel ID. This module uses only your configured channel and account-specific API host. - Create an active webhook workflow for payment_captured. Enter this connection's HTTPS webhook URL in Checkout.com. Configure an HMAC-SHA256 signing key on the webhook action and save the same value in the module's webhook secret field.
- Enter approved two-decimal invoice currencies. Save and Test; testing performs only
GET /workflows, never a payment or workflow mutation. It confirms authentication/read permission; verify the channel and captured-payment notification with sandbox checkout before enabling Live. - Switch environment and credentials together, re-test, then enable the connection explicitly.
The payer's actual billing country must be present in the customer profile; it is checked before checkout reservation. The module sends exact invoice amount/currency, a unique reference that fits card reference limits, original invoice metadata, the selected channel, and automatic capture. Checkout.com decides which approved payment methods it can offer for that country and currency.
Payment verification
Creation is followed by an authenticated payment-link read. Returns use the stored link ID from a signed application route. Notifications require an authentic Cko-Signature, then authenticated payment retrieval. Only fully Captured, approved, unrefunded/unvoided payments with original amount, currency, reference, invoice and connection metadata become payment evidence. A link's “Payment Received” status or a payment approval alone is insufficient. Stable provider payment IDs support core deduplication.
This release supports providers' captured card/wallet result flow. Other asynchronous payment methods that do not report full capture remain under billing review. Recurring debits, manual capture and automatic refunds are not implemented. A network failure after link creation requires review; checkout POSTs are never automatically retried.
Provider documentation
- Payment Links endpoints and required billing details
- Official OpenAPI authentication, metadata and capture schemas
- Payment details and balances
- Read-only workflow query and webhook signing configuration
- Signature verification
- Payment Links use gateway payment notifications
Diagnostics expose safe HTTP status/setup guidance, never raw response bodies or secrets.