Initialize Transaction
- Paymish
- Initialize Transaction
Initialize Transaction
Start a payment flow by creating a transaction session that the customer can complete using Paymish.
Endpoints
2 endpoints in this collection.
Authentication
Review each endpoint for its auth requirement before implementation.
What this section covers
- Create checkout sessions for one-time payments.
- Attach references and metadata to customer payment attempts.
- Prepare a payment before redirecting the user to Paymish.
Method mix
Build a backend payload containing amount, currency, customer details, and reference.
Send the initialize request from your server and persist the returned transaction identifiers.
Redirect the customer or continue the payment flow using the returned details.
Prerequisites
- Prepare the backend payload with the exact amount, customer details, reference, and any metadata your reconciliation flow depends on.
- Decide how you will persist the Paymish transaction identifiers alongside your internal order, invoice, or checkout record.
- Make sure your application has a clear post-initialize flow for redirecting the customer and later verifying final payment status.
Implementation Checklist
- Generate one stable reference per payment attempt and reuse it for later verification and support lookups.
- Store the initialize response before redirecting the customer so you do not lose the Paymish transaction context.
- Treat the first successful initialize call as the start of the payment flow, not the final payment confirmation.
Success Signals
- Each checkout attempt maps cleanly to one Paymish reference and one internal order or invoice.
- Support teams can look up a payment attempt from either your internal record or the Paymish transaction reference.
- Customers are redirected through a reliable flow and final payment confirmation still happens from your backend.
Common Pitfalls
- Generating a new reference every time a customer refreshes the page and fragmenting one checkout into many payment attempts.
- Treating initialization success as payment success before verification or webhook confirmation happens.
- Redirecting the customer without persisting the initialize response, which makes later reconciliation difficult.
Operational Notes
- Separate payment initialization from payment confirmation so retries, customer returns, and webhook-driven updates can all be handled safely.
- Keep enough internal metadata with each initialized transaction to support reconciliation, refunds, and support investigations later.
- Expose transaction reference and initialization state in your internal tools so support teams can diagnose checkout issues without raw logs.
Each endpoint below links to a fuller implementation guide with request structure, code examples, and response notes.
Python
Well suited for checkout orchestration where initialization, verification, and later reconciliation all run through one backend service.
Node.js
Use Node.js on the server to build checkout payloads and redirect flows, but keep final payment confirmation out of frontend-only logic.
PHP
Wrap initialize and verify calls in one payment service class so references, metadata, and redirect handling stay consistent.
cURL
Useful for understanding payload and response shape during checkout debugging, but production flows should still persist references server-side.