Keep card entry on the provider's page.
Invoice collection uses the firm's active default iyzico connection; the Vekilaw subscription account is not used. Eligible Sent/Overdue invoices require the full amount in TRY. Card entry is on the provider checkout; opening it is not payment approval.
- Card data
- No entry fields No card/CVC entry fields in the Vekilaw collection flow
- Callback
- Token A signal; the server retrieves the result
- Connection
- Setup condition HTTPS and correct callback reachability are required
- Payment record
- Scoped list Read within permission, company and branch scope
What does Vekilaw see and not see?
This tenant collection flow has no card-number, expiry-date or CVC entry fields inside Vekilaw. Card entry is on provider checkout; buyer information and payment references are processed separately.
What Vekilaw sees
- Payment amount and invoice reference
- Processed against the invoice, client, full amount and currency; the required buyer profile is also sent to the provider.
- Payment result
- The callback carries only a token. The saved tenant provider context retrieves the result server-to-server and checks signature, transaction, amount and currency.
- Payment status and record
- Payment references, the checkout reference needed for verification and a limited transaction record are retained. The checkout address is a private link; lists show payment summaries within company, branch and permission scope.
Card fields not requested in this flow
- Card number
- There is no full-card-number entry field in the Vekilaw collection flow.
- Expiry date
- There is no expiry-date entry field in the Vekilaw collection flow.
- Security code
- There is no CVC entry field in the Vekilaw collection flow.
Buyer information, payment references and provider processing/retention terms need separate assessment. Review the security page, KVKK privacy notice and current provider agreements.
An example from eligible invoice to verified result
A fictional successful scenario; it creates no real checkout, card entry, payment or notification. Successful closing requires verification and a record update. Pause or select a step to explore.
Select an eligible invoice
Failed payment, double notice, refund and subscription
- 01/04
If a payment fails
A confirmed failed result does not mark the invoice paid. Checkout already sent to the provider or with an uncertain outcome may block another request; do not start a second collection before resolving the outcome.
Failed
- 02/04
If the same payment is reported twice
Controls guard against duplicate collection when a verified result is processed again. The same actor and request can reopen ready checkout without another provider initiation. If the outcome is uncertain, check the existing attempt before starting another collection.
Guarded transition
- 03/04
If a refund is needed
This collection flow does not initiate automatic refunds. Refunds and reconciliation are managed separately under the provider account and contract; automatic mirroring of an external-panel refund into Vekilaw is not promised.
Separate process
- 04/04
Cancellation and refunds on a Vekilaw subscription
Subscriptions use a platform flow separate from tenant client collection. Cancellation disables renewal at period end; current-period access and status rules remain. The action does not issue a refund or determine legal refund rights. Review current plans and service terms.
Separate subscription flow
What is asked about payment security?
- 01/04
Does Vekilaw see my card details or my client's card details?
This flow has no card-number, expiry-date or CVC entry fields inside Vekilaw; entry is on provider checkout. Buyer information and payment references are processed separately; review current provider agreements for processing and retention terms.
- 02/04
Was the payment really completed, and how do I know?
Opening checkout or receiving a callback is insufficient: the retrieved signed result must match and an eligible record update must apply. The scoped payment list distinguishes Pending/In review/Successful/Failed. Refresh is separate; notification delivery depends on preferences, permissions, quota, provider and device conditions.
- 03/04
What happens if a payment fails?
A confirmed failure does not mark the invoice paid. Checkout sent to the provider or with an uncertain outcome may block another collection on the invoice; do not treat that as failure and create repeated links. Check the current attempt and outcome.
- 04/04
What should I do if a client asks for a refund?
Assess refunds and reconciliation separately through the provider account and relevant contract. This checkout flow does not initiate refunds or promise automatic external-panel refund matching or bank reconciliation. See the online collection scope.