Plan your integration

Decide the order to build in, and which form, amount and usage settings each payment needs.

Build in this order

Submit KYC.
Request a payment instance.
Optional: build a form.
Create a payment link for a payment anyone with the URL can make, or a payment plan to split a total into instalments for one customer.
Receive webhooks.

Make three decisions for each payment

Choose the amount mode

You want	`amount_mode`	Set
A set price	`fixed`	`amount`
The payer to choose	`open`	Optional: `min_amount`, `max_amount`
The payer to pick from preset amounts	`options`	`amount_options`, optional `allow_custom_amount`

Choose the usage mode

Scenario	`usage_mode`	Notes
One customer pays one invoice	`one_shot`	Becomes `exhausted` after the first payment.
You sell a fixed quantity	`limited`	Set `max_uses`.
A permanent "pay us" link	`reusable`	Works until you archive it.
You collect up to a target	`capped_amount`	Set `target_amount`.
Payable only during a sale or event	`time_window`	Set `starts_at` and `ends_at`.
Only specific people may pay	`whitelist`	Set `allowed_payers`.

Examples

Use case	Form	`amount_mode`	`usage_mode`
Store order with delivery details	Yes	`fixed`	`one_shot`
Bill-payment link used by every client	No	`open`	`reusable`
100 event tickets, with the attendee's name	Yes	`fixed`	`limited`
Donation drive with a goal	Optional	`open`	`capped_amount`
Private invoice for two named clients	Yes	`fixed`	`whitelist`

Keep your own IDs mapped

Store the UUID of each MyTPE resource against your own record, so you can match webhooks and reads later. Use a payment link's metadata to carry your own reference.

You never handle card data. MyTPE handles the card entry and the gateway.