Before launching a security-deposit API integration, verify the entire booking-to-deposit lifecycle: creation, customer authorization, state synchronization, supported capture and release. An HTTP success response from link creation is not evidence that a customer has reserved funds.
This acceptance checklist is for teams connecting rental software to PayRequest. It is a proposed test plan based on the public API contract, not a certification or a claim that these tests have already passed for your account.
Prepare a controlled security-deposit API test
Confirm the supported test configuration with PayRequest and your connected provider before running financial actions. Use fictitious customer records and provider-supported test credentials where available. Do not assume the documentation exposes a separate PayRequest sandbox hostname.
Keep OAuth bearer tokens server-side. The PayRequest deposit reference requires billing.read for retrieval and billing.write for creation, capture and release. Configure the webhook receiver and preserve raw request bytes for signature verification.
Choose one fictional booking, TEST-104, with a €350 deposit obligation. Record the booking reference, deposit ID, provider, current status, captured amount and capture_before deadline. Use separate bookings for final capture and release scenarios because those actions end the hold.
Run the security-deposit API acceptance matrix
The expected outcomes below reflect the documented Stripe deposit flow. Confirm account and provider support rather than applying them to every payment method.
| Scenario | Expected evidence | Acceptance condition |
|---|---|---|
| Create the same request twice with one key | Returned deposit mapping | One logical deposit, no duplicate customer message |
| Customer has not authorized | Retrieved pending state | Handover screen does not claim funds are reserved |
| Authorization attempt is processing | Pending state plus documented metadata when available | Worker does not create a replacement automatically |
| Customer completes authorization | Current authorized state and capture_before | Booking displays confirmed hold and actual deadline |
| Capture €150 of a €350 Stripe hold | Captured state and captured_amount 150.00 | €200 is shown as released, not still capturable |
| Attempt a second capture after finalization | Documented HTTP 409 for locally finalized deposit | No second charge; operator sees final state |
| Release a separate active hold | Confirmed released state | Customer copy describes release, not refund |
| Receive a duplicated or delayed notification | Current retrieved deposit and processing record | No repeated charge or stale booking-state rollback |
Preserve the request and response references needed to explain each result, without storing credentials or card details. A screenshot is useful for review, but the retrieved API state is the evidence for the financial outcome.
Test booking changes independently of payment changes
Change the return date on TEST-104 and check that your rental system does not silently extend the card authorization. Stripe's hold documentation explains that authorizations expire and capture must happen before the actual deadline.
A useful local control is a review task when the new return time approaches or exceeds capture_before. Do not automatically capture the full deposit merely to avoid expiry. The rental agreement, inspection evidence and supported provider action still determine the decision.
Keep the rental fee in its own payment-link workflow and booking availability in your booking workflow. A paid hire fee, a confirmed reservation and an active security authorization are three different facts.
Check ambiguous responses before retrying
Simulate a lost creation response and reuse the persisted creation key. For a lost capture or release response, retrieve the current deposit before deciding what to do next; creation idempotency does not prove action-wide retry guarantees. The retry recovery guide gives a dedicated worksheet.
Also review failure labels with support staff. API pending can describe an authorization attempt that is processing or expired, while expired means a previously confirmed hold expired. The integration must not treat every unsuccessful attempt as money that was reserved and then released.
What makes the integration ready for a pilot?
Require a reviewable record for every matrix row, an owner for unresolved exceptions and customer wording that matches confirmed state. Verify desktop and mobile views, webhook signature rejection, tenant isolation and read-only versus write permissions in the supported configuration.
Begin with one rental workflow through PayRequest security deposits, review plans and allowances, and use the API reference as the contract for implementation. Expand only after the pilot demonstrates correct booking and financial outcomes.
Editorial note: AI assisted with this article and cover. Documentation was reviewed on 13 October 2026. The acceptance matrix is original guidance; no live financial action was performed and no test results are claimed.
