Create a Direct API payment
Creates a payment by charging a card directly. Submit card details under
payment_method_data.card, the shopper IP in customer_ip_address, and
optional payer identity or billing data when the merchant has it.
The card number illustrates payload shape and belongs to Silverflow’s published 3DS test range. It does not guarantee a successful, declined, or 3D Secure outcome on every Sandbox account. See the test cards and 3DS cases for Silverflow processing, or use test data supplied for the account’s processor.
Every new Direct Payment goes through server-side authentication. The
response is returned immediately with the payment attempt status. If the
status is REQUIRES_ACTION, a browser action is required: redirect the customer to
next_action.redirect_url for the next_action.reason customer action,
then use GET /v1/payments/{id} as the source of truth for the final
result. Required-action redirect URLs are opaque and may change
while the payment is still REQUIRES_ACTION; redirect the customer again
only when the latest next_action.redirect_url differs from the one that
browser already visited.
return_url is required. Use an HTTPS URL; reaching it never proves
payment success.
Use the Idempotency-Key header to safely retry requests without
creating duplicate charges.
Authorizations
Use the secret API key for the intended merchant and mode as the Bearer
token. Sandbox keys start with api_test_sk_. Send the key only from
your server environment.
Headers
A unique key to ensure one effective operation is processed only once.
If the same key and an equivalent operation-specific effective request
identity have already completed successfully, the original response is
returned. A different identity returns 409 idempotency_key_reused.
Non-2xx responses are not cached, so callers may retry after errors. No
fixed retention period is promised by this contract.
For one-shot requests, such as creating a payment from a checkout button, a random UUIDv4 is fine. For requests tied to a specific business operation, such as refunding an order, a deterministic key is preferred so retries collapse correctly across processes.
255Body
Payment amount in the currency's minor units. How many minor units
make one major unit is set by the currency's ISO 4217 exponent, so
the same integer means a different value in different currencies:
4999 is EUR 49.99 (exponent 2) but JPY 4999 (exponent 0). Do not
assume two decimal places.
x >= 14999
Three-letter ISO 4217 currency code supplied when creating a payment or payout. Accepted case-insensitively and with surrounding whitespace, then normalized to a canonical uppercase code before the operation is created.
A value that is not three letters is rejected with 400 parameter_invalid
(param=currency); a well-formed code that Flowlix does not accept for
that operation is rejected with 422 currency_not_supported. Neither
creates a payment or payout. The available set is validated per request instead of
being enumerated here, so enabling another currency is not a breaking
contract change.
3 - 16^\s*[A-Za-z]{3}\s*$"EUR"
Shopper IPv4 or IPv6 address observed by the merchant during checkout. Send one literal address, not a hostname, port, or comma-separated proxy chain. Flowlix validates the complete IPv4 or IPv6 literal before registering the payment; the pattern is only an initial schema-level character and length guard.
3 - 45^(((25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])|[0-9A-Fa-f:]*:[0-9A-Fa-f:.]*)$"203.0.113.7"
Send the HTTPS URL where the customer returns after 3D Secure authentication.
"https://shop.example.com/3ds-return"
Optional merchant-side reconciliation reference. The value must contain exactly 10 decimal digits and does not provide idempotency by itself.
1000000000 <= x <= 99999999991234567890
Optional stable identifier for the shopper within the merchant account.
1 - 255"customer_42"
Optional payer contact and billing-address details for a direct payment.
Merchant-provided payment description.
500"Order #1234"
Response
Payment accepted and a Payment object was created. Check status
before treating the payment as complete; REQUIRES_ACTION includes
next_action.reason and next_action.redirect_url, while
PROCESSING should be followed with GET /v1/payments/{id}.
FAILED is a terminal Payment result, not an HTTP request error.
A Payment represents one attempt to collect funds from the customer.
Merchants can use merchant_reference to associate multiple
payment attempts with the same order or checkout in their own systems.
Unique opaque identifier for a payment (pay_ prefix + random alphanumeric suffix).
^pay_[A-Za-z0-9]{24}$"pay_q7Mk2Np8Vr4Xt6Yz9Ab3Cd5E"
Payment amount in the currency's minor units, per its ISO 4217 exponent: 4999 is EUR 49.99 but JPY 4999.
x >= 14999
Canonical uppercase three-letter ISO 4217 currency code. Responses always return the original currency the payment was created in; a provider response never replaces it.
3^[A-Z]{3}$"EUR"
Current status of a payment attempt.
PENDING-- The payment was accepted by Flowlix and is awaiting provider submission or the next lifecycle decision.REQUIRES_ACTION-- Customer action is required, such as completing 3D Secure authentication or a hosted payment page.PROCESSING-- The payment is being processed by downstream payment systems.SUCCEEDED-- The payment completed successfully.FAILED-- The payment was declined or failed permanently.EXPIRED-- The customer did not complete a required action before its expiry time.
PENDING, REQUIRES_ACTION, PROCESSING, SUCCEEDED, FAILED, EXPIRED "SUCCEEDED"
How the payment was collected. This is separate from the payment method
instrument, such as card.
DIRECT, HOSTED_PAYMENT_PAGE "DIRECT"
Total amount successfully refunded so far, in the payment currency's minor units, per its ISO 4217 exponent.
x >= 00
Remaining amount that can be refunded, in the payment currency's minor units, per its ISO 4217 exponent.
x >= 04999
Unix timestamp when the payment was created.
1719792000
Always false for a Payment created in Sandbox.
false
Merchant-side reconciliation reference, if provided.
1000000000 <= x <= 99999999991234567890
Merchant-provided payment description.
"Order #1234"
Masked card details, or null before card details are available.
Billing details captured for the payment, if available.
Machine-readable reason code when the payment reaches a terminal failed status.
not_found, processor_error, processor_unavailable, generic_decline, do_not_honor, issuer_declined, insufficient_funds, invalid_number, invalid_expiry, expired_card, invalid_amount, invalid_currency, not_permitted, cardholder_limit, card_velocity_exceeded, lost_card, stolen_card, suspect_fraud, fraud_filter, three_d_secure_failed, three_d_secure_timeout, three_d_secure_not_supported, three_d_secure_error "insufficient_funds"
Human-readable explanation when the payment reaches a terminal failed status.
"The card has insufficient funds."
Refunds created for this payment, oldest first.
Timestamps for important payment status transitions.
Customer action required to continue the payment.