Unclear payment state
The application treats a redirect or browser message as the final result.
TRINAITRA SOLUTIONS / PAYMENT GATEWAY INTEGRATION
Payments connected to the workflowbehind them.
Integrate a suitable payment gateway with your website, store, portal or custom application—with verified payment states, failure handling and operational reconciliation.
Checkout · Verification · Webhooks · Reconciliation · Refunds · Testing
Beyond the pay button
Accepting a payment
is only one step.
A payment attempt affects an order, booking, invoice, membership or service request. If these records are not connected correctly, customers may see the wrong status, teams may fulfil unpaid orders and successful payments may remain unmatched.
Disconnected records
Provider transactions and internal orders cannot be matched reliably.
Weak failure handling
Pending, cancelled or failed attempts leave customers unsure what to do next.
Manual reconciliation
The team compares provider reports and business records manually.
Choose the right payment experience
Use the simplest secure flow
that meets the requirement.
Hosted checkout
- Customer continues through a provider-hosted page or supported checkout experience.
- Reduces direct handling of sensitive payment fields.
- Suitable for many standard payment journeys.
- Branding and behaviour depend on provider capabilities.
Provider-controlled embedded components
- Payment fields are rendered through supported provider components.
- Can offer a more integrated experience.
- Requires careful implementation using current provider documentation.
- Security and compliance scope must still be assessed.
Payment links
- Useful for suitable invoice, service or assisted-payment workflows.
- May reduce custom application work.
- Order matching and customer communication still require planning.
- Availability depends on the provider.
A fully custom collection of raw card details should not be presented as the default option. Use supported provider-controlled experiences wherever suitable.
Provider fit
Select a gateway around the business—
not a feature logo list.
- Merchant and industry eligibility
- Supported regions and currencies
- Required payment methods
- Website, app or platform compatibility
- Hosted checkout and SDK options
- API and webhook quality
- Test environment
- Refund and dispute operations
- Settlement and reconciliation reporting
- Security and compliance documentation
- Support availability
- Pricing and contract terms
- Integration and maintenance effort
Provider availability, approval, fees, reserves, limits, payment methods and settlement terms are controlled by the provider and may change.
Payment lifecycle
A payment can move through
several valid states.
Created
The business creates an internal order, invoice or payment request.
Initiated
The customer begins the provider-controlled payment journey.
Pending
The final result is not yet confirmed and the business should not assume success or failure.
Successful
The provider-supported server-side flow confirms the payment.
Failed or cancelled
The attempt did not complete and the customer receives an appropriate next step.
Refund initiated
An authorised refund request is submitted where supported.
Refunded or adjusted
The application records the verified provider outcome.
Exact provider states differ. The implementation should map provider-specific events to a clear internal business state rather than exposing raw provider terminology everywhere.
Separate but connected
An order record and a payment record
are not the same thing.
Business record may represent
- Order
- Appointment
- Invoice
- Subscription request
- Membership
- Service booking
- Fee payment
Payment record may include
- Internal payment reference
- Provider transaction reference
- Amount and currency
- Current status
- Attempt history
- Verified event references
- Refund status
- Reconciliation state
- Non-sensitive provider metadata
01
Server-created amount
The payable amount should be created or validated on the trusted server side.
02
Stable reference
The provider transaction must map back to the correct business record.
03
No sensitive card storage
Do not store raw card number, CVV or equivalent sensitive authentication data.
Source of truth
Do not mark an order paid
from the browser alone.
A success page is useful for customer experience, but browser navigation can be interrupted, repeated or manipulated. The application should confirm the result through the provider's supported server-side API, verified webhook event or other documented server-side mechanism.
Customer completes or exits the provider flow
The customer may return to the site, close the browser or remain on a provider page.
The server verifies the relevant provider result
The trusted server checks the payment state through supported provider mechanisms.
The internal payment and business records update safely
Order, invoice or booking status changes only after verified confirmation.
The final implementation must follow the selected provider's current documentation.
Verified events
Process provider events once—
even when they arrive more than once.
Receive the event
Accept the provider event on a server endpoint.
Preserve the payload
Keep the payload format required for verification.
Verify the signature
Validate the provider signature using the documented method.
Reject invalid requests
Return an appropriate response when verification fails.
Check for prior processing
Determine whether the event was already handled.
Record or queue the event
Store verified event references for audit and idempotency.
Resolve the associated records
Locate the linked payment and business record.
Apply an idempotent transition
Update status without creating duplicate business actions.
Acknowledge the event
Return the provider-required acknowledgement promptly.
Log exceptions
Make failed delivery and processing observable for authorised review.
- Webhook secrets remain server-side.
- Duplicate delivery must not create duplicate fulfilment, invoices or credits.
- Event order must not be assumed.
- The latest provider state may need to be retrieved during reconciliation.
- Only relevant event types should be processed.
- Failed delivery and processing should remain observable.
- Manual replay must also be safe.
Payment reconciliation
Make mismatches visible
before they become customer problems.
Matched
The internal amount, provider transaction and expected business record agree.
Pending
The payment is still processing or waiting for a reliable final state.
Unmatched
A provider transaction or internal payment record lacks a valid counterpart.
Mismatched
Amount, currency, status or reference requires authorised review.
- Successful but unfulfilled
- Paid amount mismatch
- Failed order with later successful payment
- Duplicate payment attempt
- Refund pending
- Provider event not processed
- Internal record missing
- Manual adjustment requiring a reason
Automated reconciliation can highlight exceptions, but authorised users should review cases that cannot be resolved safely.
Design for failure
A failed payment should not
become a dead end.
Customer cancellation
The customer exits before completing payment.
Authentication failure
Additional verification required by the provider does not complete.
Provider timeout
The provider does not return a final result within the expected window.
Pending payment
The attempt remains in an intermediate state awaiting confirmation.
Network interruption
Connectivity issues interrupt the customer or server-side flow.
Duplicate customer attempt
The customer retries payment while an earlier attempt may still be processing.
- Use a clear non-technical message.
- Do not claim failure if the status is still pending.
- Allow a safe retry where appropriate.
- Do not create a second payable business record unnecessarily.
- Preserve the order reference.
- Provide a support route for unresolved cases.
- Avoid exposing provider error details or sensitive information.
- Confirm later success through the server-side flow.
Post-payment operations
The workflow continues
after payment success.
Refunds
- Authorised initiation
- Full or partial support where available
- Provider reference
- Internal status tracking
- Customer communication
- Failure or pending-state handling
Disputes and chargebacks
- Provider notification visibility
- Supporting-record ownership
- Restricted access
- Deadline awareness
- Manual business review
Settlements
- Provider-controlled settlement reporting
- Transaction-to-settlement references
- Fee visibility where available
- Exception review
- Finance-team handoff
Refund, dispute and settlement capabilities, timing and outcomes are controlled by the selected provider, financial institutions and applicable rules. Trinaitra cannot guarantee them.
Security boundaries
Keep sensitive payment handling
with the systems designed for it.
- Prefer provider-hosted or provider-controlled payment interfaces where suitable.
- Never expose secret API keys in browser code.
- Keep webhook secrets server-side.
- Verify signed provider events.
- Use HTTPS in live environments.
- Avoid storing raw card numbers or CVV.
- Redact sensitive data from logs.
- Restrict access to payment operations.
- Record important manual actions.
- Separate test and live credentials.
- Rotate compromised secrets.
- Review third-party scripts on payment-related pages.
- Keep dependencies and provider SDKs maintained.
- Define incident and escalation ownership.
Payment security and PCI DSS responsibilities depend on the selected provider, integration method, merchant environment and operational practices. Trinaitra integration work does not by itself certify PCI compliance.
Test before live
Validate more than
one successful payment.
- Successful payment
- Failed payment
- Customer cancellation
- Pending or delayed result
- Browser closed before redirect
- Duplicate checkout attempt
- Duplicate webhook event
- Out-of-order event
- Invalid webhook signature
- Amount or reference mismatch
- Refund success
- Refund pending or failure
- Provider API unavailable
- Internal processing failure after provider success
- Mobile and desktop journeys
- Test/live credential separation
Provider readiness
Merchant account and required provider configuration are ready.
Test scenarios pass
Critical success, failure, pending and duplicate paths are validated.
Webhook verification active
Webhook endpoint and signature verification are active.
Duplicate protection confirmed
Duplicate processing protection is confirmed.
Reconciliation ownership defined
Reconciliation and exception ownership are defined.
Customer messages reviewed
Customer-facing messages and support routes are reviewed.
Monitoring available
Monitoring and logs are available to authorised users.
Live validation complete
A controlled live transaction is validated after activation.
How we implement
Map the transaction, secure the integration
and test every important state.
Requirement assessment
Understand the business record, amount logic, customer journey, region and operational needs.
Provider and flow selection
Evaluate suitable providers and choose hosted checkout, components or payment links.
Integration design
Define server-side creation, references, statuses, webhooks, reconciliation and exceptions.
Secure implementation
Connect supported provider APIs while keeping secrets and sensitive payment handling outside the browser.
Testing and review
Validate success, failure, pending, duplicate, refund and recovery scenarios.
Activation and handover
Move through provider readiness, controlled live validation, monitoring and team guidance.
What you receive
A payment flow connected
to the business record behind it.
- Payment-flow assessment
- Provider-selection considerations
- Internal state and reference mapping
- Provider checkout integration within scope
- Server-side payment creation
- Verified webhook handler
- Duplicate-event protection
- Order/payment reconciliation flow
- Failure and retry experience
- Refund-status workflow where included
- Test scenario checklist
- Live-activation checklist
- Operational guidance
- Known limitations and provider dependencies
Exact deliverables depend on the selected provider, platform, business model, payment methods, merchant eligibility and agreed scope.
FAQs
Common questions before you start.
Which payment gateway should we use?
The right provider depends on merchant eligibility, geography, currency, payment methods, platform compatibility, operational requirements, fees and support. We assess these factors before recommending an integration approach.
Can Trinaitra guarantee gateway approval?
No. Merchant onboarding, KYC, industry eligibility, limits and approval are controlled by the payment provider and associated financial institutions.
Can the gateway be integrated into our existing website?
Often yes. Feasibility depends on the website technology, backend access, order workflow, hosting environment and the selected provider's supported integration options.
Do you store customers' card details?
The integration should use supported provider-controlled payment experiences and must not store raw card numbers, CVV or equivalent sensitive authentication data in Trinaitra application code.
Why are webhooks required?
Many payment results are asynchronous. Verified webhooks help the application receive provider events even when the customer closes the browser or does not return to the website.
What happens if the same webhook arrives twice?
The handler should identify already-processed events or make the business operation idempotent so duplicate delivery does not create duplicate fulfilment, invoices, credits or status changes.
Can you support refunds?
Refund initiation and tracking can be included where the selected provider supports it. Processing time, final outcome and settlement impact remain provider-controlled.
Does integration make our website PCI compliant?
No automatic compliance claim should be made. PCI DSS scope and responsibilities depend on the provider, integration method, website environment and merchant practices. Qualified compliance guidance may be required.
What costs are involved?
Costs may include implementation, provider transaction charges, platform fees, applicable taxes and ongoing support. Provider pricing and settlement terms can change and should be confirmed directly for the selected account.
How long does integration take?
The timeline depends on merchant-account readiness, website architecture, provider flow, payment methods, backend logic, testing and operational requirements. A plan is prepared after assessment.
Start with the transaction
What should happen before and after a customer pays?
Share your website or application, business record and current payment process. We'll help map the right provider flow, verification approach and operational handoff.