account option. The PaymentIntent belongs to that merchant, who
receives the payment. Use the same merchant ID when creating the intent on
your server and mounting the Block in the browser.
How Connect works explains platform and merchant
roles. The Blocks guide covers the shared payment
features and options.
Before you begin
- Platform test keys from Connect → API keys, with the secret key on your server.
- An active connection granting
payments:writeandpayments:read, with those permissions also on the platform key. - Your page’s origin registered for the same mode in Connect → Payment domains.
@ionicfi/sdk0.4.1 or later and@ionicfi/js0.2.1 or later.
Select the connected merchant
GET /v1/connected_accounts lists the platform’s connections. Each data[].id
is a connected merchant ID. This platform-level request takes no
Ionic-Account header.
A merchant-scoped request uses Ionic-Account, or the server SDK’s account
request option. The selected merchant, amount, and access to the resulting
intent must come from your application’s authorization decisions.
Create the PaymentIntent on your server
Use your platform’s secret key and the selected merchant’s ID. The PaymentIntent specifies the payment amount; itsclient_secret lets the
browser display a Block for that payment.
requestKey represents the application-assigned key for this operation.
Repeating the operation uses the same key and body. The key’s scope includes the
receiving merchant and mode. See Idempotency.
The create response contains client_secret; secret-key retrieval does not
return its value. The browser needs authorized access to that secret, the
platform publishable key, and the matching connected merchant ID.
Mount the Payment Block on your page
Add an empty HTML element where you want the payment form to appear:client_secret returned when that merchant’s PaymentIntent
was created.
blocks.create("payment") creates the Payment Block.
payment.mount("#payment") displays it inside the <div id="payment"> on
your page. #payment is the CSS selector for that element. The Block shows
Ionic’s card fields, or the intent’s status when card entry is no longer available.
Ionic automatically loads the secure card fields in an iframe hosted at
embed.ionicfi.com. If your site uses a Content Security Policy, follow the
CSP configuration.
Mounting displays the Block. Submitting the payment is a separate call to
confirmPayment.
Confirm the payment and read its status
ionic.confirmPayment({ blocks }) submits the card details from the mounted
Block for its PaymentIntent when your customer chooses to pay.
ionic.retrievePaymentIntent(clientSecret) reads that payment’s current status.
Both calls use the connected merchant selected in loadIonic. The
confirmation methods and
retry limits are the same as for a
direct merchant.
The merchant is fixed for the client’s lifetime. blocks.destroy() removes
the UI without canceling a submitted payment. A different merchant requires a
new client and an intent belonging to that merchant.
Keep payment data with the correct merchant
Different merchants may use the same reference. A reference does not identify
a merchant or authorize access to a client secret. Any application lookup or
reuse must preserve the intended merchant and mode as well as the intent’s
identity. A platform API key’s access to both merchants does not authorize a
customer to access both merchants’ payments.
Platform payment events
A platform webhook endpoint belongs to the platform, so endpoint creation uses platform keys withoutIonic-Account. The Program needs connect_webhooks, the
key needs webhook-management permissions, and the merchant’s connection needs
payments:read for payment events. See
Platform webhooks.
event.account identifies the connected merchant. A verified signature proves
the delivery’s authenticity, not its association with an application’s purchase.
The merchant, mode, intent ID, amount, and currency must match the intended
payment. reference alone cannot establish that association.
Events may be duplicated or arrive out of order. Your application decides how
to record payment outcomes and apply fulfillment policy using the
event and delivery contracts.
Save a card during the payment
A PaymentIntent with the same merchant’scustomer and
setup_future_usage: "off_session" enables optional saving. The customer’s
consent determines whether saving is requested. See
Save the card being entered.
For saving without payment, see Save cards for connected merchants.
For live-mode setup, see Going live.
