id is new, or updates the existing payment when it already belongs to the merchant on the access token. id is the Fire spark payment UUID and is required on every item. Send only the fields to change.
Requires an access token with the
payments:write scope. See
Token to obtain a token.merchant_id and env come from the token. When creating, payment_provider_id and payment_method_id are required. The method must belong to that provider. Omitted status becomes ACTIVE. Omitted scope arrays mean every store, channel, brand, and fulfillment. Send null on an existing payment to return a scope to every id. private_key and webhook_signature are stored but omitted from the response.
Sending config, rules, or conditions replaces that field entirely. Omitting one leaves the stored value.
Config
config is validated against the provider slug, method, and version on the catalog rows.
Any other provider, method, or version accepts a JSON object. On create, an omitted
config is validated as {}.
A firespark REDEMPTION payment is one custom redemption source (vouchers, Yape, Masivo, and so on). The payment name and config.logo_url identify that source, so storefronts show them instead of the Fire spark provider logo. logo_url is public and is returned in responses and to the storefront.
kushki:
Rules
rules is an array of inclusive order-total windows. Each item needs minimum_order_value and maximum_order_value (0 to 1,000,000). [] means there is no amount gate. An omitted rules on create is stored as [].
Conditions
conditions is an OR of AND groups: the outer array is OR, and each inner array is AND. [] means the payment is eligible whenever its scope matches. An omitted conditions on create is stored as [].
Each condition needs primitive, type, operator, and value. Optional fields: interpretation (client, server, or both) and invalidMessage.
Checkout primitives you can send:
Order includes product also needs product_id. Order includes product with tag also needs tag.
This example offers the payment when the order total is at least 10, or when the cart has 3 or more products:
Request
id plus the fields described above.
Response
Zod validates the entire body before saving. If any field is invalid, HTTP400 is returned and no items are saved. When the body is valid, items are saved one after another. HTTP 200 only when every item is saved. If a later item hits a business error, HTTP is that item’s status (422 or 500).