Payments

Retrieve the PDF representation of the receipt for a given payment in base64 format. Provide paymentId and optionally isForMerchant (default: true): true = merchant copy, false = customer copy.

Calculate the surcharge/fee rate for a given card BIN and amount. Returns the surcharge amount, rate, type, and card brand. Use this before charging to display the final amount to customers. binCard is the first 6 digits of the card — derive it from the masked card.number returned by the tokenization callback. tokenId is the single-use payment token. On the Strictly gateway BOTH must be sent (tokenId required, binCard non-empty). This call does not consume the token.

Create a payment and immediately flag it for settlement when capture=true (default). A payment can be made for a card or for an existing customer vault. Set capture=false to issue a pre-authorization only — call /capture separately to settle.

Customer vault: If charging a customer vault, the system uses the default payment method. Override with overrideDefaultPaymentMethod set to the desired customerVaultId.

Dual-pricing accounts: amount represents the card price; no surcharge or discount applies for Regular/Dualpricing accounts.

Sandbox/test mode: Use token 00000000-000000-000000-000000000000 to speed up integration without hitting the network.

To trigger a declined response (sandbox): Pass an amount below 100 (less than $1.00).

bypassSurcharge: Set to true to remove surcharge for exceptions.

card.number must be the masked card number from the tokenization form (e.g. 411111******1111), regex: \d{6}[*\.]+\d{4}. When charging with a token (no card.vaultId), card.number is required in addition to card.paymentToken (error code 905 otherwise). With card.vaultId neither is needed.

Surcharge: send the base amount only. The surcharge is computed server-side from amount and the card BIN and added to the charged total, also when charging with card.paymentToken. Sending a pre-surcharged total applies it twice.

Error codes: 901 = card or payment method required, 902 = VaultId or PaymentToken required, 904 = transaction type not allowed for the merchant, 905 = card number required, 906 = customer not found. These are returned with the code as the HTTP status (e.g. HTTP 905) and as a numeric response.code, with the reason in response.text. Such statuses are outside the standard 100–599 range and some HTTP clients surface them as a transport error instead of a response.

Post a refund on a previously captured payment. Funds are returned to the original credit/debit card. You can refund the full amount or only a portion. Multiple partial refunds are allowed until the charge is fully refunded. Attempting to refund a fully-refunded payment will result in an error. amount is an integer in cents (1000 = $10.00).

Refunds require a settled payment — unsettled payments must be voided (POST /void) instead.

Set receipt=true to send a refund receipt; email/phoneNumber override the payment contact.

The response also includes a card object (cardType, last4, exp, type) describing the refunded card.

Void an existing payment that has not yet been settled. Once voided, no additional charges can be made. For settled/captured payments, use the refund endpoint instead.

reason values: fraud, user_cancel, icc_rejected, icc_card_removed, icc_no_confirmation, pos_timeout, rejected, insufficient_funds, incorrect_information, pop_timeout.

Set receipt=true to send a receipt notification to the customer via email or SMS; email/phoneNumber override the payment contact.

The user-agent header is recorded on the void transaction but not validated.

400 errors share the same status; distinguish them by response.text: This payment can not be voided because it has been settled already, Not found a transaction with id: ....

Flag a pre-authorized payment for settlement. Only payments in status auth (created with capture=false and not yet captured or voided) can be captured. You can capture an amount equal to or less than the original pre-authorization. Uncaptured payments are not posted to the account until a settlement runs (by default, daily).

Receipt: when the original payment was created with sendReceipt=true and has a contact email, a receipt is sent automatically; receipt, email and phoneNumber are ignored on capture.

Processor declines may be returned with HTTP 201 and error: true in data; always check data.error.

Returns the merchant surcharge acknowledgment (disclosure) text with the merchant credit rate filled in, for display in terminal flows. type controls the response format: json (default, one paragraph per key) or text (paragraphs joined). The response is not wrapped in data.

Retrieve a single payment record by ID. There is no list endpoint under /payment; use GET /public/transactions to list payments.

Create a payment from a customer vault for each entry in the payments array. Equivalent to calling /charge for a customer multiple times. Processed asynchronously via a Pub/Sub queue — the response only confirms the job was queued. Poll individual payment IDs to check each charge result.

Required per-item fields: amount, customerVaultId. Optional: bypassSurcharge (true/false) to remove surcharge for exceptions.