Payment Link Features

Detailed guide to the advanced options available when generating a payment link — CoreID, redirect URLs, payment splitting, and webhook notifications.

Customer CoreID

CoreID is a unique blockchain-based identifier for the payer. When generating a payment link, you can optionally pre-fill the customer CoreID or require the payer to provide one before completing the transaction.

The CoreID is not used for payment processing itself — it is included in the webhook payload sent to your server after a successful payment. This allows you to match incoming payments to specific customers in your system.

-- Pre-filled CoreID — If you already know your customer's CoreID, enter it in the field. It will be locked in and sent with the webhook data.
-- Force collecting CoreID — Enable this checkbox to require the payer to enter their CoreID before they can complete the payment. Useful when you need to identify the payer but don't have their CoreID in advance.

If a valid CoreID is pre-filled, the force collection checkbox is automatically disabled since the ID is already known.

Redirect URL

The redirect URL determines where the payer is sent after completing a payment. If not specified, the payer stays on the CorePort success page.

When a redirect URL is provided, CorePort appends query parameters to it so your application can verify the payment:

-- tx — The transaction hash on the blockchain.
-- status — The payment status (e.g., "completed").
-- amount — The payment amount.
-- currency — The settlement currency.

The redirect URL must be a valid HTTPS URL. Always verify the payment on your server using the webhook or API rather than relying solely on redirect parameters, as URL parameters can be tampered with.

Split Payments

Split payments allow you to divide a single payment across multiple wallet addresses. This is useful for marketplaces, revenue sharing, or distributing funds to multiple parties automatically.

Each split entry requires a wallet address (or CoreID) and a percentage. The first address is the primary receiver — additional addresses receive their specified percentage of the total amount.

-- The primary receiver gets the remaining percentage after all splits are deducted.
-- Split percentages must add up to less than 100% (the remainder goes to the primary address).
-- Split addresses can be reordered by dragging.
-- Split payments are only available for PayTo payment method — a warning is shown if other methods are selected.

Splits are calculated on the net amount after fees. The fee is deducted first, then the remaining amount is distributed according to the split configuration.

Webhooks

Webhooks allow your server to receive real-time notifications when a payment is completed. When generating a payment link, you can specify a webhook URL where CorePort will send a POST request with the payment details.

The webhook payload includes the transaction ID, amount, currency, customer CoreID (if provided), timestamp, and any custom data you attached to the payment link.

-- Webhook requests include an X-JWS-Signature header with a detached JWS (ES256) of the canonical JSON body. Public verification keys are published as a JWK Set at /.well-known/jwks.json.
-- Your server should respond with a 200 status code to acknowledge receipt.
-- If the webhook delivery fails, CorePort will retry the request.

For the full webhook payload structure, security details, and signature verification instructions, see the dedicated Webhook Documentation page.