Payment links
Create InAppify web payment links, connect offerings and apps, customize checkout, identify customers, apply discounts, and configure return actions.
A payment link opens a checkout page hosted by InAppify. Customers select an offering package and pay without you building a checkout page from scratch. Products, prices, and access come from your project configuration.
“Web purchase link” refers to the same feature. These links sell project products; they are not links for paying your InAppify account invoices.
Products, offerings, and payment links
- Product: the item purchased, with a catalog price.
- Offering package: defines presentation, descriptions, and package discounts.
- Payment link: displays the offering's packages for the selected web app.
- Entitlement: access granted after a successful purchase, not after merely opening a link or visiting a gateway.
Changing a link's title or appearance does not change product prices or access. When an offering contains products for several apps, checkout only displays packages containing a product for the selected web app.
Prerequisites
- Create a project and web or PWA app.
- Define products and prices and attach entitlements.
- Create an offering and packages containing products from that web app.
- Complete payment configuration.
- Decide on a stable customer identifier and return destinations.
Team members need the corresponding permissions to view, create, edit, or customize links. This uses web checkout, not the in-store purchase flow of Cafe Bazaar or Myket.
Create a link in the dashboard
- Sign in to the dashboard and select your project.
- Open Payment links from the project menu.
- Select the add-purchase-link action to open the creation form.
- Enter an internal name and select an offering and web configuration.
- Enter the checkout title, description, and terms URL.
- Enable the discount-code input if needed.
- Choose the post-payment behavior and configure its destinations.
- Save, then customize the appearance and copy a customer-specific link from the details page.
Form settings
| Setting | Purpose |
|---|---|
| Internal name | Identify the link in the dashboard, such as “Website subscription checkout”. |
| Offering | Packages presented to customers. |
| Web configuration | The web app associated with the offering. |
| Title and description | Customer-facing text above checkout; explain the purchase clearly. |
| Terms URL | Your business's valid terms page, such as https://example.com/terms. |
| Allow discount codes | Show the code input; discount rules are configured separately. |
| Post-payment behavior | Choose continuation buttons after the result; applies to this link. |
The current system allows one payment link per offering. An offering already linked is unavailable for another link; deactivation does not remove the association. An existing link's offering cannot be changed. Create the link associated with a different offering instead.
Missing offerings or apps
An offering must belong to the selected project, contain web-app products in its packages, and not already have another payment link. The web-app picker is populated from the offering's products; creating an app alone is insufficient.
For an empty checkout, check whether packages contain products for the selected web app. Test prices, entitlement associations, and gateway configuration before sharing.
Customize checkout appearance
Select Edit appearance from the details page. Customize page and card backgrounds, title and description colors and alignment, selected and unselected packages, prices and discount badges, buttons, inputs, success and error colors, and corner radii.
The live preview illustrates appearance; its sample prices and copy are not actual purchase results. Save changes and open the real link on desktop and mobile. Resetting to the default template resets appearance, not products or the link itself.
Keep text readable, selected packages distinguishable, and final prices clear. This customizes a predefined template; it is not a free-form paywall editor or an arbitrary-code input.
Generate a customer-specific URL
Select Share link from the details page, enter the customer's app user identifier, and copy the generated URL. Example structure:
Copy the actual URL from the dashboard; the system generates the link identifier. The final path segment is the customer's app_user_identifier, not an internal numeric customer ID. The dashboard URL-encodes this value.
Use the same identifier as your app or SDK. Sharing one identifier among different customers combines their purchases and access under one identity. If the customer does not exist, starting a purchase creates the customer in that project; merely opening checkout does not.
A URL without a customer identifier is incomplete. An identifier in the URL is not a password or proof of customer authentication. Control customer identity in your own app or website when generating links, and never include passwords, login tokens, or sensitive information in URLs. See customer identity.
Discount codes
Create the discount under Web discounts and enable the link's code input. Customers can enter a code, or you can append the code query parameter:
Codes must qualify for the project, customer, and product. The server calculates the final amount; package and code percentages are not added together. See discount codes for examples and eligibility rules.
Post-payment behavior
| Option | Customer experience | Requirement |
|---|---|---|
| Show result only | Stay on the payment result page. | No continuation destination. |
| PWA button | Continue to the web app associated with the link. | A return URL configured for that web app. |
| Native app button | Open the selected native app. | A direct Android or iOS app in the same project with a configured return link. |
| Both buttons | Choose the PWA or native app. | Both destinations configured. |
Choose the destination native app from the list; Bazaar and Myket apps are not included. For missing destinations, check app settings and return links. Opening a native app also depends on installation and device support for the destination link.
These options configure continuation buttons, not automatic redirects or payment verification. Refresh customer access through the authoritative system or SDK after returning; URL parameters or a clicked return button do not prove successful payment.
Purchase flow and result
The customer selects a package and starts checkout. The server validates the product's app and offering, entitlement association, and discounted price before initiating the gateway flow. After the gateway returns, the server verifies the payment and grants access for a successful purchase.
A zero final amount completes without external payment, but product and entitlement checks still apply. Failed or cancelled payments are not successful purchases.
Edit or stop a link
Open the edit action from the list or details page. Update copy, the permitted web configuration, discounts, and return behavior; the offering cannot be replaced. Change products or package prices through the catalog and offering configuration.
Deactivate a link to stop new purchases. It no longer serves active checkout or accepts new purchases. This does not cancel previous successful purchases or revoke customer access; do not assume it cancels a payment already initiated either.
Troubleshooting and launch checks
- Link does not open: check the full URL, customer identifier, and activation.
- Offering unavailable: check web products and an existing payment link.
- Missing products or packages: confirm the selected web app's product is in the offering package.
- Purchase cannot start: check entitlements, prices, and gateway settings.
- Code rejected: check customer and product eligibility in the discount guide.
- Continuation button missing or app not opening: check the selected mode, destinations, and app installation.
Before launch, open links for two different customer identifiers, verify packages and amounts, and test success, failure, and app return using your approved testing method. Creating a link or viewing its preview is not a payment test. Follow the test-purchase checklist.