Opening your page…
Please wait a moment
RuhaPay developers · Early-access preview
From your first access request to planning reliable payment handling, find the guidance you need for supported BBPS services in one place.
01 · Getting started
Start with your business use case and prepare your backend while partner access is being readied. The following stages describe the planned onboarding process.
Tell us about your business and the platform you want to integrate.
Once sandbox onboarding opens, our team reviews your application before enabling test credentials.
Integrate in an isolated test environment and verify payments, retries and callbacks.
Submit integration results and business details for a separate live-access review.
Only after production approval can you generate credentials and use enabled live services.
02 · Integration guide
Use these design checks to prepare your application. Exact request fields, authentication, retry rules and callback signatures must come from the released API specification.
Route payment requests through your backend. Store secrets securely and keep them out of browser code, mobile bundles, URLs and logs. Use separate configuration for test and live environments.
Prepare: secure secret storage, HTTPS and restricted access to configuration.
Discover the supported biller and its required customer fields. Fetch or validate the bill where required, then confirm the customer, amount and bill details before payment. Use the released contract for amount units and validation rules.
Prepare: field validation and an explicit customer confirmation step.
Persist your own order reference before submitting. If a response is delayed or lost, retain the payment as unresolved and enquire about its status before retrying. Follow the released idempotency contract; never create a second payment just because the first request timed out.
Prepare: durable order records and protection against repeated submissions.
An HTTP success response does not prove that a bill was paid. Plan to verify callback authenticity using the released signature rules, deduplicate events and handle delayed or out-of-order updates. Reconcile unresolved payments through the documented status enquiry process.
Prepare: an HTTPS callback receiver, event records and reconciliation jobs.
Once your sandbox access is approved, capture the result and transaction references for each scenario before requesting production review.
Show the field error and allow correction before another submission.
Record the final result and show the matching customer message.
Keep the outcome unresolved and check status before taking further action.
Ensure repeated clicks and retries cannot create duplicate payments.
Process events safely without applying the same update twice.
Recover the outcome through status enquiry and reconciliation.
03 · Common questions
This public page provides integration planning and an early-access inquiry form. Executable endpoint examples, self-service sandbox execution and public credentials are not available in this preview. Use only the API contract supplied for your approved environment.
No. The form records your interest and returns an inquiry reference. Keep that reference for follow-up. Account onboarding, permissions and credentials are handled separately.
Sandbox access is reviewed separately from production. The planned sandbox uses isolated test data and balances. Live access requires business review and integration evidence; sandbox approval alone does not enable live operations. Provider UAT testing may also be required.
Planned capabilities include discovery, bill fetch, validation, payments, status and receipts for supported BBPS billers. Availability, pricing, permitted services and limits depend on the released API and your approved account configuration.
Versioned schemas, authentication instructions, error codes, signature rules and verified examples will be published with the released sandbox contract. No endpoint paths, headers or payload formats should be inferred from this planning guide.
Include your inquiry reference, or the request and transaction references provided by your approved integration, along with the environment, time and a redacted description of the issue. Do not send credentials, OTPs or customer-sensitive payloads.
04 · Request access
Share your business details, the services you need and your expected integration use case. Our team can use these details to discuss onboarding with you.
Keep the inquiry reference after submitting. This form records your interest; it does not create an account or enable sandbox or live payments.
Review the access FAQ ↑
