Skip to main content
On this page

The Voucher widget presents the instructions or reference generated for a supported voucher or cash-based payment method. It uses an existing order token; it does not create or pay a second order.

Voucher lifecycle#

01 · backend
Create the order
Create an order that is eligible for the configured voucher method.
02 · app
Open Voucher
Pass the returned order_token to the platform SDK.
03 · customer
Save the instructions
The customer views, copies, or downloads the supported reference.
04 · backend
Confirm payment
Wait for the authoritative asynchronous order status before fulfillment.
Sequence diagram
1Merchant app2DEUNA API3Voucher widget4CustomerCreate eligible orderorder_tokenOpen with the same tokenVoucher / referenceinstructionsCopy or downloadVerified webhook orretrieved state
Merchant or customerDEUNA

Open the widget#

await DeunaSDK.initVoucherWidget({
  orderToken,
  language: 'en',
  callbacks: {
    onSuccess: (data) => showVoucherInstructions(data),
    onError: (error) => showRecovery(error),
    onClosed: () => showPaymentMethods(),
    onPaymentProcessing: () => disableDuplicateActions(),
  },
});

Parameters#

ParameterPlatformsRequiredPurpose
orderTokenAllYesToken for the existing voucher-eligible order.
callbacksAllYesSuccess, error, close, event, and supported payment-processing handlers.
languageAllNoSupported widget language. Web types currently accept en, es, or pt.
modeReact NativeYesmodal or the supported embedded renderer mode.
fraudCredentialsNative + React NativeNoProvider credentials only when the configured fraud flow requires them.
customUserAgentiOS + AndroidNoApp-specific WebView user agent for an approved integration need.
domainAllNoEnvironment override for controlled testing; omit in normal production integrations.

Completion and payment state#

onSuccess means the voucher experience completed its supported client action. Voucher settlement commonly occurs later, outside the app. Keep the order pending in your interface until your backend observes the final state through a verified webhook or an API retrieval.

SituationCustomer messageMerchant action
Instructions displayed“Use these instructions to complete payment.”Persist the merchant order ID and wait for a state change.
Widget closed“You can return to this order later.”Do not cancel or recreate automatically. Reconcile first.
Network error“We could not load the voucher.”Offer a retry with the same order token.
Voucher paid“Payment confirmed.”Fulfill only after backend verification.
Voucher expired or rejectedExplain the supported next step.Move to a terminal or retryable state from the API response.

Receipts and file delivery#

A reference-payment response can contain a reference_processors array. Each available processor entry can provide a barcode, expiration date, processor name, and hosted HTML or PDF receipt URL. Because this field is an array, the hosted Voucher experience can present more than one receipt when the processed payment returns multiple reference processors.

Flow diagram
NoYes1Reference paymentresponse2reference_processorspresent?3Show the widget'ssupportedcontinuation4Present one or morereceipts5View processorinstructions6Open, save, or sharethe availablereceipt7Keep payment pendinguntil backendconfirmation
Result or outcomeProvider or processorReview or pending

The processor decides which receipt fields are present. Do not synthesize a PDF URL from a barcode or assume that every reference method has both HTML and PDF formats.

PlatformDownload ownershipIntegration behavior
WebHosted widget and browserThe widget presents the available receipt action. The current Web callback contract has no dedicated file callback.
React NativeMerchant applicationonDownloadFile receives {type, data}. type is url when the processor supplies a receipt URL, or base64 when the SDK captured the current voucher view.
AndroidNative SDKThe SDK downloads the supplied receipt URL or saves a snapshot fallback when the widget emits the save action. Test storage and sharing behavior on supported Android versions.
iOSNative SDKThe SDK downloads the supplied receipt URL or captures the current view as a fallback. Test the resulting save/share experience on supported iOS versions.

For React Native, branch on the discriminator instead of assuming the payload is always a file body:

JavaScript
import {DownloadType} from '@deuna/react-native-sdk';

const onDownloadFile = async ({type, data}) => {
  if (type === DownloadType.URL) {
    await openTrustedReceiptUrl(data);
    return;
  }

  await saveBase64VoucherImage(data);
};

Validate any URL before opening or fetching it, use HTTPS, keep downloaded files inside an appropriate protected or user-selected location, and do not log receipt contents. A saved receipt is customer-facing evidence; it is not authoritative payment-settlement confirmation.

Mobile and accessibility#

  • Present Voucher from a visible screen, not from a background callback.
  • Keep download, copy, and close actions reachable at 200% text size.
  • On React Native, request only the storage or sharing capability needed by your save implementation.
  • Restore focus to the control that opened the modal and announce load errors through the platform accessibility API.
  • Test the reference with long merchant names, long localized instructions, and narrow devices.

Troubleshooting#

The widget reports an invalid order tokenToken validation

Confirm that the string is non-empty, belongs to the selected environment, and comes from the same order you intend to show. Do not exchange a private API key or raw order body with the client.

No voucher instructions appearEligibility

Confirm the order and payment method are configured for a voucher flow. A generic card order does not become a voucher order by opening this widget.

The success callback fired but the order is still pendingExpected asynchronous state

This can be expected for cash and voucher methods. The callback completed the UI action, not settlement. Continue listening for the verified backend state.