Drop-in throws TypeError on Enter key when onSubmit is not configured

[damusnet]

Description

When a Drop-in is initialized without an onSubmit callback (a valid setup when the host app drives submission via its own button and uses the Drop-in only as an encrypted-field collector), pressing Enter inside any Drop-in input crashes with:

TypeError: undefined is not an object (evaluating 'this.makePaymentsCall().then')

Stacktrace

@adyen/adyen-web/src/components/Dropin/Dropin.tsx:242  Dropin.handleKeyPress
@adyen/adyen-web/src/components/internal/UIElement/UIElement.tsx:502  UIElement.handleKeyPress
@adyen/adyen-web/src/components/Dropin/Dropin.tsx:249  Dropin.onEnterKeyPressed
@adyen/adyen-web/src/components/internal/UIElement/UIElement.tsx:516  UIElement.onEnterKeyPressed
@adyen/adyen-web/src/components/internal/UIElement/UIElement.tsx:224  UIElement.setStatus

makePaymentsCall() returns undefined when no onSubmit is configured, and the Enter-key path then calls .then() on it unconditionally.

Reproduction

const checkout = await AdyenCheckout({
  clientKey: '...',
  environment: 'test',
  countryCode: 'US',
  showPayButton: false,
  // no onSubmit
  paymentMethodsResponse: {
    paymentMethods: [{ type: 'scheme', brands: ['visa'], name: 'Credit Card' }],
  },
})

new Dropin(checkout, {
  paymentMethodsConfiguration: {
    card: { billingAddressRequired: true, billingAddressRequiredFields: ['postalCode'] },
  },
}).mount('#dropin')

1. Fill in card details.
2. Focus the billing postal code field.
3. Press Enter (or "Go" on a mobile keyboard).
4. → TypeError thrown from makePaymentsCall().then.

Reproduces on mobile Safari (iOS 18.7) and desktop browsers. We see ~140 occurrences across 113 users in production.

Expected behavior

Either:

1. Guard makePaymentsCall to no-op (or warn) when no onSubmit is configured, instead of throwing.
2. Throw a clear error at init time if a Drop-in is constructed without onSubmit, so integrators discover the misconfiguration immediately rather than via a runtime TypeError deep in a keypress handler.

A clearer error at init would have let us identify and fix our integration in minutes instead of triaging a cryptic Sentry stack.

Workaround

Provide a no-op onSubmit that resolves immediately:

onSubmit: (_state, _component, actions) => {
  actions.resolve({ resultCode: 'Received' })
}

Environment

• @adyen/adyen-web: 6.33.0
• Browser: Mobile Safari 26.1 / iOS 18.7 (also reproducible on desktop)
• Framework: Next.js 16 + React 19

[ribeiroguilherme]

Hi @damusnet ,

Why aren't you using the onSubmit to perform the payments call in this case? What are you using instead? How are you getting the payment data to perform the /payments call?

There is indeed an uncaught exception for this particular scenario which we indeed have to fix, although there is a also a proper error propagated on onError that reports the problem. But regardless, we have to fix this uncaught one.

About the expected behavior - we do want to improve our API validation during init time and we are investigating that, but there are no timelines for that yet.

Cheers

[damusnet]

@ribeiroguilherme we retrieve the encrypted data in onChange and handle our own submit button, which passes Adyen and other form data to our backend, which is responsible for validation and payment submission.

[github-actions]

This issue is stale because it has been open 21 days with no activity. Please comment on this issue otherwise it will be closed in 7 days.

[damusnet]

@ribeiroguilherme is this still being considered, or should I close?

[github-actions]

This issue is stale because it has been open 21 days with no activity. Please comment on this issue otherwise it will be closed in 7 days.