How money flows through Bumpr

1. Why there is no checkout page to visit

Bumpr is an online travel marketplace selling same-day stays in villas in Bali, Indonesia, at discounted standby prices. It is sold through a native iOS and Android app — there is no web shop and no browser checkout, so there is no cart to click through.

Every payment is initiated server-side by the backend that serves this page. The card itself is entered in the Airwallex mobile payment sheet inside the app. This document describes that path end to end, in the same order the money moves.

2. The path, step by step

1. 1Guest, in the Bumpr app

   Books a villa

   The app calls POST /api/bookings on this host. The booking is written with status pending_payment — nothing is confirmed yet.

2. 2Bumpr backend

   Creates an Airwallex PaymentIntent in USD

   The guest is first resolved to an Airwallex Customer — POST /api/v1/pa/customers/create, once per account, looked up on every payment after that. Then a server-side call to POST /api/v1/pa/payment_intents/create carrying the USD amount, merchant_order_id = booking id, a stable request_id idempotency key, and that customer_id. The client_secret comes back to the app.

3. 3Airwallex SDK, inside the app

   Takes the card

   The Airwallex mobile payment sheet collects and submits the card details. The number, expiry and security code are never sent to, or stored on, a Bumpr server — what comes back to us is the PaymentIntent id. The sheet also offers to save the card, which creates a customer-initiated payment consent held by Airwallex, so the next booking opens on the saved card instead of an empty form. Bumpr never charges a saved card without the guest present.

4. 4Airwallex → Bumpr backend

   Confirms the payment by webhook

   payment_intent.succeeded is delivered to POST /api/webhooks/airwallex on this host, signature-checked, de-duplicated, and only then is the booking moved to confirmed. Confirmation is never taken from the client.

5. 5Guest, whenever they choose

   Removes a saved card

   Payment Methods in the app lists the guest’s saved cards and removes any of them with POST /api/v1/pa/payment_consents/{id}/disable. The request is refused unless the consent belongs to that guest’s own Customer. Deleting the account revokes every saved card first.

6. 6Guest

   Stays at the villa

   Funds sit with Bumpr for the length of the stay. Bumpr is the merchant of record throughout.

7. 7Bumpr backend

   Pays the villa owner in IDR

   Once the booking’s check-out date has arrived, a scheduled job creates the payout and calls POST /api/v1/transfers/create — source_currency: USD → transfer_currency: IDR, transfer_method: LOCAL — to the owner’s Indonesian bank account. Airwallex confirms with payout.transfer.paid.

3. Who gets what

A booking price has exactly two parts. The accommodation is the villa owner’s money; the service fee is Bumpr’s revenue. The guest is charged the sum of the two as a single amount.

• Accommodation — the villa’s standby nightly rate × the number of nights. Paid out in full to the owner.
• Bumpr service fee — a percentage of the accommodation, set per villa and 15% by default. This is our only revenue on a booking.
• Currency — prices are held in IDR and the guest is charged in USD, converted at an exchange rate locked at the moment of booking. That same locked rate is reused for every later refund and payout on the booking, so a guest is never re-priced by an FX move.

Worked example — 3 nights at 1,800,000 IDR, at 16,300 IDR/USD

The guest sees and is charged one USD amount. The owner receives 5,400,000 IDR into an Indonesian bank account after check-out.

4. When money moves

These timings are the ones published in our Refund & Cancellation Policy.

5. What triggers a refund

Refunds always go back to the original card, in the currency of the original charge. Four things trigger one. The amount in each case is set by our Refund & Cancellation Policy, which is the authoritative statement of what a guest gets back; this page describes how the money moves, not how much.

• Cancellation — the guest cancels before checking in.
• Early departure — the guest leaves partway through the stay, and the nights they do not use are refunded.
• A bump — Bumpr sells a flexible product: a booking can be cut short with 18 hours’ notice, which is what pays for the discount. If it happens, the unused nights are refunded together with their share of the service fee. Nights already stayed are charged as normal.
• Villa switch — the guest moves to a different villa; the original booking is refunded and the replacement is a new booking at its own price.

A booking can carry more than one charge — the original plus a charge per paid extension, each its own PaymentIntent. Refunds are therefore distributed across those intents oldest-first, and each allocation is capped at that intent’s captured amount minus anything already refunded against it. A booking can never be refunded for more than it was charged, and a retried refund finds nothing left to give back rather than paying twice.

6. Merchant of record

Bumpr ApS is the merchant of record for every booking. In the words of our Terms & Conditions: “Bumpr is the merchant of record for bookings: you book and pay through the Platform, and Bumpr pays the Owner.”

Villa owners are independent businesses. They are paid by Bumpr after the stay; they never take a payment from the guest directly, and there is no card flow between guest and owner.

7. Card data and PCI scope

Card details are captured by the Airwallex mobile SDK and submitted straight to Airwallex. The card number, expiry and security code never pass through a Bumpr server and are never stored by us. What we persist against a booking is the PaymentIntent id, the refund id, the transfer id and the amounts.

The most we ever hold about the instrument itself is the non-sensitive display data a payment provider returns — card brand and last four digits — as stated in our Privacy Policy.

8. The integration, in detail

All server-to-server calls are made from this backend against Airwallex API version 2024-09-27, authenticated with our client id and API key.

Calls Bumpr makes to Airwallex

Bumpr endpoints on this host

Webhook events consumed

• Authenticity — every webhook is verified with an HMAC-SHA256 signature over timestamp + raw body, compared in constant time. An unverified event is rejected.
• Replay — delivered events are recorded and de-duplicated, so Airwallex’s retries are safe and a repeated event cannot confirm a booking or pay an owner twice.
• Idempotency — every charge, refund and transfer carries a stable request_id derived from our own row id, never a timestamp. A retry returns the original object instead of creating a second one.
• Reconciliation — a scheduled job re-reads PaymentIntents and transfers directly from Airwallex, so a webhook that never arrives is caught rather than leaving a booking or payout stuck.

9. Contact

Bumpr ApS · CVR 46460960 · Denmark · teis@thingmark.dk

Related documents: Terms & Conditions · Refund & Cancellation Policy · Privacy Policy · bumpr.rent