Our widget provides a variety of payment options to best fit your users and your integration. This reference details when are where each payment option should be used.
The following payment methods are supported within the Widget:
|Type||Credit Card||Apple Pay||Google Pay|
|iOS Webview (< iOS 13)||✓||x||x|
|iOS Webview (>= iOS 13)||✓||✓ ***||x|
|Android Webview||✓||x||x *|
|Android Custom Tabs||✓||x||✓|
|Stand Alone (not embedded)||✓||✓ **||✓|
* | The payment button will show up in the Widget, however, it will not work properly
** | Only supported in Safari. Button shouldn't show up in other browsers.
A detailed reference of payment types and processes is provided below.
Credit card payment is supported in all versions of the widget. In this form of checkout, the user will have to input their credit card information directly into the widget. This checkout experience looks and feels exactly as it does within the ParkWhiz website, without the need for page redirect.
Apple Pay support is contingent on whether you're using a device that support Apple Pay. Please see the following link for more details.
Google Pay support is available on most browsers and devices.
Using the Guest Checkout UI Component Arrive will automatically handle and process payment in-app.
- Arrive handles payment processing
- User stays within the native experience
- Payment information is not saved
- Apple and Google pay are not supported
There are cases in which it's preferred to have checkout on the ParkWhiz website rather than within the widget. These cases can include:
- Your site or application is not running in
- There's not enough screen real estate to render the checkout page successfully
- Your site or application is not mobile responsive
As long as the value
checkout is not included in the parameter list
ui-components within your widget URL the user will be redirected to payment on the ParkWhiz website.
- Payment information is saved to the user's ParkWhiz account
- All payment types are supported
- User is redirected outside of the native experience
- User's payment information is not passed back to the partner
If you'd like the user to bypass payment entirely, and would prefer that we send you an invoice totaling all purchases from within your applications, please reach out to our Partner Support Team.
- You have full control of the payment flow prior to booking
- Purchases are not updated in real-time
Using the Payment Callback you can invoke your own native payment service within your application. This can be bundled with Pay on Invoice or handled separately.
- You have full control of the payment flow
- Payment purchases are handled in your internal processor
- Additional development work is required
- Additional support work is required to settle payments and refunds