Split card payments in SDKs
Configure and operate a two-card split payment through DEUNA Payment Widget or Elements on supported SDKs.
On this page
Split card payments let a customer distribute one order across multiple cards in a supported DEUNA experience. The current public SDK examples configure two cards with behavior.paymentMethods.creditCard.splitPayments.maxCards.
See split payments in checkout#
The following demo shows a customer dividing one order across two cards in the DEUNA checkout experience:
Use the demo for visual orientation. Your backend must still reconcile every attempt and verify the overall order state before fulfillment.
Payment flow#
Enable the behavior#
await DeunaSDK.initPaymentWidget({
orderToken,
behavior: {
paymentMethods: {
creditCard: {
splitPayments: {maxCards: 2},
},
},
},
callbacks,
});await deunaSDK.initPaymentWidget({
orderToken,
mode: 'modal',
behavior: {
paymentMethods: {
creditCard: {
splitPayments: {maxCards: 2},
},
},
},
callbacks,
});let behavior: Json = [
"paymentMethods": [
"creditCard": [
"splitPayments": ["maxCards": 2]
]
]
]
deunaSDK.initPaymentWidget(
orderToken: orderToken,
callbacks: callbacks,
behavior: behavior
)val behavior: Json = mapOf(
"paymentMethods" to mapOf(
"creditCard" to mapOf(
"splitPayments" to mapOf("maxCards" to 2)
)
)
)
deunaSDK.initPaymentWidget(
context = this,
orderToken = orderToken,
callbacks = callbacks,
behavior = behavior
)Web and React Native type the behavior object. iOS and Android accept the same public shape as JSON. Keep key spelling and nesting exactly as shown.
Events and callbacks#
| Signal | Use |
|---|---|
onCardBinDetected / onBinDetected | Detect the active card’s BIN without collecting raw card data. |
onInstallmentSelected | Associate the selected plan option with the card currently being configured. |
paymentMethodSplitPayments | Native Elements event indicating the split-payment path. |
paymentProcessing / onPaymentProcessing | Lock duplicate actions while the combined operation is in flight. |
purchase, purchaseError, purchaseRejected | Client lifecycle only; always reconcile the order and its attempts. |
Do not reconstruct the financial result by summing client events. Use the current backend order and transaction records.
Failure and recovery#
Split payments can create a partial operational outcome: one attempt can reach a different state from another. Design the recovery path before enabling the feature.
| Scenario | Merchant behavior |
|---|---|
| First card fails before another succeeds | Keep the order open only if the current order state permits another attempt. |
| One card succeeds and the other fails | Reconcile both attempts; do not submit a new full-order payment blindly. |
| Customer closes mid-flow | Retrieve the order before restoring payment options. |
| Client loses connectivity | Treat the result as unknown until the backend responds. |
| Duplicate tap or retry | Reuse your operation controls and documented idempotency strategy. |
Test matrix#
- Two cards with exact allocation and supported currency precision.
- Installments on an eligible card and no installments on an ineligible card.
- Decline on the first and second card separately.
- App backgrounding, refresh, or network loss between cards.
- Customer closure after entering one card.
- Slow authorization and repeated submit gestures.
- Final webhook and API state matching the customer confirmation screen.