Payments
The Payment components offer users one or more methods of entering credit card and/or other payment information.
- Standard Credit Card Payment
- Examples
- Examples
- Developer Notes
- Card Number
- Card Number with Error
- Card Expiration
- Card Expiration with Error
- Card Security Code (CVV)
- Card Security Code (CVV) with Information Popover
- Card Security Code (CVV) with Error
- Unified Credit Card Input
- Unified Credit Card Input with Error
- Advanced Usage
- Currency Input
- Right-to-Left Support
- Accessibility Notes
Standard Credit Card Payment
Examples
- Standard Credit Card Payment (shown above)
- Standard Fields with Address
- Multiple Payment Options (Accordion)
Examples
Standard Credit Card Fields with Address
This version is identical to the standard credit card payment example, but it also includes input fields for capturing the user’s address.
CREDIT CARD INFORMATION
BILLING ADDRESS
When to Use
- Users are required to enter an address along with the credit card information.
Multiple Payment Options (Accordion)
This version allows users to choose from a small, limited set of accepted payment types.
Sign In to pay with a card on file.
Phasellus cursus purus eu varius finibus. Praesent pretium nisi est, nec aliquet nulla sollicitudin eget. Maecenas lacinia mi in neque scelerisque.
When to Use
- Users can select a payment type other than credit card.
- There is a relatively small number of options from which to choose (less than 5).
When Not to Use
- When only one category is offered (for example, the user can only pay by credit card).
- When users can combine multiple payment options.
Multiple Payment Options (Select)
This version allows users to choose from a dropdown of accepted payment types.
Phasellus cursus purus eu varius finibus. Praesent pretium nisi est, nec aliquet nulla sollicitudin eget. Maecenas lacinia mi in neque scelerisque.
When to Use
- There are more than four non-credit card payment types from which to choose.
- There are space constraints and using a select (dropdown) is preferable to the accordion version.
Unified Credit Card Fields
This example streamlines the process by auto-advancing the user through the input fields.
When to Use
- This version is recommended for touch interfaces, at small and extra small breakpoint sizes.
Currency Input
Currency Inputs capture monetary values and have display options that account for localization.
Developer Notes
Card Number
A Card Number Input is created using the class .spark-payment--card-number
. It is then instantiated using new Spark.Payments.CardNumber(el)
. The following options may be passed when using new Spark.Payments.CardNumber(el, {});
:
The Card Number Input provides mechanisms to get and set values with or without formatting, and with additional checks for validity. For all available methods and full API, refer to the component code on Bitbucket. For detailed usage around manipulating supported card types with the cardTypes
and disableCardDefaults
params, refer to Advanced Usage.
Card Number with Error
Card Expiration
A Card Expiration Date Input is created using the class .spark-payment--expiration
. It is then instantiated using new Spark.Payments.CardExpiration(el)
. The following options may be passed when using new Spark.Payments.CardExpiration(el, {});
:
The Card Expiration Input provides mechanisms to get and set values with or without formatting, and with additional checks for validity. For all available methods and full API, refer to the component code on Bitbucket.
Card Expiration with Error
Card Security Code (CVV)
A Card Security Code Input is created using the class .spark-payment--card-security-code
. It is then instantiated using new Spark.Payments.CardSecurityCode(el)
. The following options may be passed when using new Spark.Payments.CardSecurityCode(el, {});
:
For all available methods and full API, refer to the component code on Bitbucket.
Card Security Code (CVV) with Information Popover
Card Security Code (CVV) with Error
Card Set Deprecated
A Card Set is an optional wrapper around one set of Card Number, Card Expiration, and Card Security Code inputs. It can be used to instantiate the set of fields at once, and offers control of the set of fields from a single object. A Card Set is created using the class .spark-payment--card-set
and is instantiated using new Spark.Payments.CardSet(el);
. The following options may be passed when using new Spark.Payments.CardSet(el, {});:
Additional Card Set Properties
For all available methods and full API, refer to the component code on Bitbucket.
Unified Credit Card Input
A Unified Card Input is created using the class .spark-payment--unified
and is instantiated using new Spark.Payments.UnifiedCreditCard(el);
. The following options may be passed when using new Spark.Payments.UnifiedCreditCard(el, {});:
Additional Unified Credit Card Input Properties
For all available methods and full API, refer to the component code on Bitbucket.
Unified Credit Card Input with Error
Advanced Usage
Spark Payment Card Number Inputs may be extended if the card type and/or number format you require is not already supported in what the component ships with. The component has a series of internally stored card type configurations used to enable it’s unique behavior. These configurations can be overwritten or appended to, to extend on current configurations or add support for additional card types, by passing card type configuration objects in through the cardTypes
param on instantiation.
A card type configuration is an Object
cardTypes
parameter where the key
is a unique string representive of the type. This may be anything, but must be all lowercase, and contain no special characters. Card Type configurations have a property for the card type name, length of the card number, length of the security code, the number prefix that identifies a card as this type, and the pattern for which the card number is displayed.
Card Type Configuration
Here is an example card type for UATP cards
Multiple Values
If a card type has multiple possible lengths and/or patterns, length
and pattern
properties should be provided in an array
, where the order of values in each array align. So in example, for a card type that has 2 different lengths and associated patterns, the value of pattern[0]
should align with the value of length[0]
, and the value of pattern[1]
should align with the value of length[1]
.
Another property which can be passed an array
of values is the prefix
property. If your card type has multiple prefixes, bundle them into an array. Prefixe values may also be an array if they represent a range.
Here is an example card type for VISA cards, which have variable card number lengths and patterns, as well as a series of prefixes.
Card Type Images
If extending with an additional card type, you’ll need to provide your own image, and write a little CSS. The unique string you choose to represent your card type with will be used in constructing values which will appear on the component in the event it detects the card type, so you may display your own card type image with the following CSS.
Card type images are 48px
x 36px
, though if you wish to overwrite the styles for current images or supply images for additional card types, you won’t have to worry about modifying any further display styles. Card type images appear as a background-image
for a container displayed at 2rem
x 2rem
, and have a further background-size
property that will use the image to fill the full width of the available area while maintaining the aspect ratio. The component currently uses SVG
images, so it is recommended that any additional images you configure also be as well. SVG
images are vector based and can be scaled infinitely, which means they support all retina devices out of the box, so there are currently no styles written to support multiple images designed to be paired against specific pixel densities. If you wish to use an alternative image type such as PNG
, JPEG
, or GIF
, you’ll need to write any additional varying pixel density styles to support retina devices yourself.
Current Card Type Configurations
Disabling Default Card Types
If your product only accepts a subset of the different card types documented above, you may want to prevent a situation where the user could see the logo for a card type you don’t accept.
For example, if a product is only capable of processing credit card payments made with MasterCard or Visa, you should disable other card types otherwise a user could see a UATP card logo if a card number starting with 1
is typed in for instance.
To disable support for card types you don’t currently need, first locate the unique IDs for those you wish to disable by referencing the Current Card Type Configurations table above. Once you have the IDs for the card types you wish to disable, pass them into disableCardDefaults
as an array
on instantiation.
Below is an example which disables China Union Pay, Diners Club, JCB, and UATP, leaving default configurations in place only for American Express, Discover, MasterCard, and Visa cards.
Currency Input
A Currency Input is created using the class .spark-payment--currency
. It is then instantiated using new Spark.Payments.CurrencyInput(el)
. The following options may be passed when using new Spark.Payments.CurrencyInput(el, {});
:
Note: The Currency Input follows the IEEE 754 standard for Floating-Point arithmetic, and as such should not be used for extremely large values.
Right-to-Left Support
Accessibility Notes
Using CVV Inputs with Popovers
When using a Popover with the CVV Input, an aria-label
is required on the Popover’s toggle to allow assistive technologies to convey the purpose of the control. A label is provided by default but it can be overridden as necessary using the available infoToggleAriaLabel
option. Refer to the Popover’s accessibility documentation for more information on how to make it accessible.