Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Build the integration around a Node.js server that holds PonchoPay credentials and decides whether an order is paid; Flutter should request hosted checkout and display its result, not declare payment settled. PonchoPay’s indexed API documentation describes an integration key, demo and production API URLs, and distinct callback states. Confirm the current API contract and webhook signature rules in your provider account before implementing: the underlying documentation page was unavailable when opened, and a third-party tutorial’s Node.js package is not verified as official.

What you need before writing code

PonchoPay Support says providers can find API integration details in their account settings. Payment methods and capabilities can depend on provider settings or booking-platform configuration, so confirm which methods are enabled before creating payments.

  • Provider access: Obtain the current integration key and environment settings through your PonchoPay provider account. Keep the key on your server, never in the Flutter app or a public repository.
  • HTTPS: PonchoPay’s indexed API documentation states that HTTPS is required for all API requests.
  • Enabled payment method: The guide says at least one method must be enabled in the provider admin before creating payments.
  • Current API details: Confirm base URLs, request schemas, callback configuration, and available payment methods against the current account documentation before deployment.

The indexed guide lists https://demo.ponchopay.com/api/ as the demo base URL and https://pay.ponchopay.com/api/ as the production base URL. Treat these as details to verify with PonchoPay, not as a substitute for the current account instructions.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose payment states that match the payment method

Do not reduce every callback to a single “paid” state. In particular, a payer reporting that a standard Tax-Free Childcare (TFC) or childcare voucher payment is complete does not prove that the money has arrived in your bank.

Callback Meaning in PonchoPay’s indexed guide Implementation implication
payment_captured Card pre-authorization completed for certain TFC or childcare voucher flows. For card or express TFC payments, it can occur with payment_completed. Interpret it in the context of the payment route; do not assume it is a universal bank-receipt signal.
payment_reported_complete The payer manually marked a standard TFC or childcare voucher payment complete. Record the report, but do not treat it alone as confirmation that funds have arrived.
payment_completed Funds were successfully processed or captured for some routes; for some standard TFC or voucher routes, a reported payment was identified as in-bank. Use the route and current provider status semantics to decide what business action is safe.
payment_in_bank PonchoPay identifies the payment in the childcare provider’s bank account. The event is not available for every payment type. Do not make this the sole completion path for methods that do not emit it.
payment_refunded, payment_cancelled, payment_updated Refund, cancellation, or payment update callbacks; not all are available for every payment. Handle only the event types configured and supported for the account, and keep order records consistent with changes.

For some standard TFC and childcare voucher payments, the indexed guide says identification as in-bank may take two or more days because of voucher-provider terms. That is a documented possibility, not a universal timing guarantee. Ask PonchoPay which confirmation state is appropriate for your fulfillment policy and payment methods.

Keep checkout and payment authority on the server

A safe architecture separates the client’s checkout experience from the server’s payment record. The following is an implementation pattern, not a verified PonchoPay SDK contract or a prescribed set of endpoint names.

  1. Flutter asks your application server to start checkout. Send an authenticated request tied to an order already known to your system. Do not send the PonchoPay secret key from the app.
  2. Your Node.js server creates the payment. Use the current PonchoPay API instructions and the account’s enabled payment method. Associate the returned payment reference with the application’s order record.
  3. The server returns the hosted-checkout URL to Flutter. Open it using the client experience supported by your app and the provider’s current checkout instructions.
  4. Flutter handles navigation, then asks your server for order status. A redirect, WebView close event, or return to the app is navigation feedback—not proof that payment settled.
  5. Your server changes authoritative payment state from verified callbacks and its payment record. Fulfill only when the state appropriate to that payment route and business policy has been confirmed.

Keep payment creation, credentials, callback validation, and order-state decisions in the server-side application. The precise endpoint names, payloads, redirect or deep-link setup, and Flutter plugin are not established by the available provider material.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Receive and validate callbacks in Node.js

PonchoPay’s indexed guide says callbacks can be configured in provider settings and include an HMAC signature in a signature header. It strongly advises checking the signature. The accessible material does not establish the exact header name, canonicalization method, digest details, retry behavior, or event ordering; obtain those particulars from the current official specification rather than guessing.

  1. Configure a public HTTPS callback endpoint in the provider settings, using the current URL and event configuration instructions.
  2. Read the raw request bytes as required by the official signature specification. JSON parsing or re-serialization can change the bytes used for verification.
  3. Verify the signature before acting. Reject invalid signatures and do not process their payment instructions.
  4. Persist the event and payment identifiers available in the verified payload. Use them to match the callback to a server-side payment and order; do not trust a client-supplied status as the payment record.
  5. Apply changes idempotently. Repeated delivery should not create duplicate fulfillment or reverse an already-handled business action. This is prudent application design, not a stated PonchoPay retry guarantee.
  6. Reconcile before fulfillment. Check the event against the payment record and the meaning of that payment method’s state. Do not assume callbacks arrive in a guaranteed order.

The exact signature algorithm inputs and callback payload contract must come from PonchoPay’s current documentation. Until those are confirmed, an implementation cannot safely invent an HMAC check from the fact that a signature header exists.

What is and is not established about a Node.js SDK

A third-party tutorial names @ponchopay/pp-nodejs and an isValidCallback helper, but the available official material does not confirm that this package is official, maintained, or supported. Do not build a production integration around those claims unless PonchoPay confirms them through its current provider documentation or support channel.

Whether you use a provider-approved SDK or direct HTTPS requests, keep secrets and payment authority server-side, follow the current API schemas, and validate callbacks using the provider’s exact signature rules.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Test the methods and failure paths your account supports

PonchoPay’s indexed guide recommends testing card, TFC, and childcare voucher payments, as applicable, as well as abandoned checkout and callback handling. Run only methods enabled on the provider account.

  • Complete each enabled method and confirm the expected payment state and admin record.
  • Leave checkout unfinished and confirm that the order does not become paid merely because the app returned or closed its checkout view.
  • Exercise each callback type configured for the account, including applicable refunds, cancellations, and updates.
  • Check handling of invalid signatures and repeated events, and verify that a callback is matched to the correct server-side payment.
  • For standard TFC or voucher flows, account for the gap between a payer reporting completion and any later in-bank identification; do not assume those states occur simultaneously.

Support’s February 20, 2025 onboarding article describes dashboard payment statuses such as in progress, complete, and in bank. Those account views can help with operational reconciliation, but they do not replace server-side verification or define an API callback guarantee.

Sources and scope

PonchoPay’s API integration documentation is available here as an indexed extract covering setup, callback names, signatures, and test recommendations; its underlying Notion page returned 404 when opened: PonchoPay API Integration Guide. Treat volatile technical details as unconfirmed until checked against the current provider account documentation.

PonchoPay Support’s article “I’ve completed onboarding, what’s next?”, dated February 20, 2025, confirms that API integration details are available in provider account settings and describes payment-status context. It also says that, under its payment-guarantee description, payments not completed within 14 days are deemed overdue; this support context is not a universal API rule.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.