1. Fix the operating scope
Document who contracts with merchants, who processes and settles funds, which countries and currencies are in scope, and which payment and payout flows are required at launch. A clear boundary prevents the build from absorbing every future idea.
2. Map providers and failure paths
List the contracted providers, their supported methods and transaction states, plus what should happen when a route is unavailable or a payment fails. Routing and cascading should be designed before production traffic arrives.
3. Configure the operating layer
- Merchant hierarchy and onboarding states
- Tariffs, fees and payment-method access
- Roles, permissions and approval paths
- Ledger records and reconciliation sources
- Monitoring, support and incident ownership
4. Integrate, test and release
Connect providers and client systems, then test successful, failed, reversed, retried and partially completed flows. PulsePay deployments can start from three weeks when scope and dependencies are ready; exact timing depends on integrations, custom logic and acceptance requirements.
Frequently asked questions
- How fast can PulsePay be deployed?
- Delivery can start from three weeks for a defined scope with ready dependencies. Provider onboarding, customisation, compliance review and client-side integration can extend the timeline.
- Do provider contracts need to be in place first?
- They should at least be identified and commercially progressing. Technical credentials, certification and provider approval often sit on the critical path to go-live.