Example Payment Forms
Illustrative checkout pages a platform could build with Preczn's browser SDKs, and who builds each part.
Preczn doesn't provide a checkout page. You design and build every checkout in your own app. Preczn's browser SDKs render only the inputs where a customer enters payment details, and you place those inputs on a page you own.
This page shows what a checkout built that way could look like. The examples are illustrations, not templates, hosted pages, or features you can turn on. Each one is set in Hedgerow, a fictional software platform for landscaping businesses, where the merchant Cedar Hollow Landscaping collects payments from its customers. Hedgerow designed every layout, label, and button on these pages, except the Apple Pay and Google Pay buttons, which are Apple's and Google's own. The highlighted parts show where Preczn's SDK renders inputs. Names, dates, and amounts are made up.
Illustrative examples onlyThe mockups on this page have no code, design files, or hosted versions behind them. To build a checkout, start from the integration guides linked in each example, and design the page your customers see.
Who builds what
Every checkout on this page uses the same split. You build the page. With PaymentElements or a wallet button, Preczn renders the inputs that capture payment details.
| Part of the checkout | Who renders it |
|---|---|
| The page, layout, branding, and copy | You |
| Amount, invoice details, and line items | You |
| First name, last name, ZIP code, and other non-payment fields | You |
| The pay button, confirmation, and receipt | You |
| Card number, expiration, and security code, with PaymentElements | Preczn, as three separate inputs, each in its own iframe |
| Bank account fields, with PaymentElements | Preczn, each input in its own iframe |
| Card fields, with PaymentFields | You, as your own inputs that PaymentFields reads |
| Google Pay button and payment sheet | Google's button component, which Preczn renders inside an iframe. See Google Pay for Web. |
| Apple Pay button | Apple, through the <apple-pay-button> element you place on your page. See Apple Pay on the Web. |
| 3D Secure challenge | Preczn, in a lightbox your page opens when the issuer asks for one. Available on Stripe and Stripe Connect connections. See 3D Secure Integration. |
| The transaction | Your server, with your private API key |
What you can style
You control everything outside the Preczn inputs. Inside PaymentElements inputs, you set text styles such as color, font, and size through configure(), from an allowed list. See Configure styles and placeholders. The Google Pay button has its own appearance options. See Customize the button's appearance.
Apple Pay and Google Pay buttons
Apple and Google set their own rules for how their buttons, marks, and names appear on your checkout. Before you add a wallet button, read the requirements in Google Pay for Web and the guideline links in the testing checklist of Apple Pay on the Web.
Examples
Each example below is independent and uses the same Preczn inputs in a different layout. None of them is a product. A real Hedgerow checkout would look however Hedgerow designs it.
| If your customers ... | See ... |
|---|---|
| Pay an invoice from a link | Pay an invoice online |
| Prefer to pay from a bank account | Offer bank account payments |
| Pay on a schedule | Save a card for recurring service |
| Have cards that their bank asks to verify | Handle a card that needs verification |
Pay an invoice online
In the example below, Hedgerow has decided to email Cedar Hollow's invoices to Cedar Hollow's customers, with a link to a payment page that Hedgerow hosts on its own domain. Hedgerow put the invoice on the left and the payment options on the right.
Illustration only: a payment page that Hedgerow designed. The Apple Pay and Google Pay buttons are the official buttons, rendered by Apple's and Google's scripts. The highlighted Google Pay button and card inputs are rendered by Preczn. Everything else is Hedgerow's.
| On screen | Who builds it |
|---|---|
| Invoice details, line items, and total | Hedgerow, from its own invoice data |
| Pay with Apple Pay | Apple renders it from the <apple-pay-button> element Hedgerow places on the page, with type="pay". Preczn's client returns the token. |
| Pay with Google Pay | Preczn renders Google's button inside the <div data-preczn="googlepay"> that Hedgerow places on the page, with buttonType: "pay". |
| Card number, expiration, and security code | Preczn renders each input in its own iframe. Hedgerow writes the labels, sets placeholder text and text styles with configure(), and styles the containers. |
| First name, last name, and ZIP code | Hedgerow's own inputs. Hedgerow's server sends them with the transaction as firstName, lastName, and billingAddress.postal. |
| Pay $485.00 | Hedgerow's button. It asks Preczn for a single-use token, sends the token to Hedgerow's server, and the server creates the sale. |
Hedgerow has stacked both wallet buttons above its own Pay button, at the same size. To build this, start with PaymentElements Integration, Google Pay for Web, and Apple Pay on the Web. Apple Pay works only on domains you verify. See Apple Pay Domain Verification.
Offer bank account payments
Some homeowners prefer to pay a large invoice from a bank account. In the example below, Hedgerow has decided to add a Bank account tab to the same payment page, and to stack the page into one column on a phone.
Illustration only: a mobile payment page that Hedgerow designed. The highlighted bank account inputs are rendered by Preczn. Everything else is Hedgerow's.
| On screen | Who builds it |
|---|---|
| Card and Bank account tabs | Hedgerow |
| First name and last name | Hedgerow's own inputs. Hedgerow's server sends them with the transaction as firstName and lastName, which personal bank accounts require. |
| Routing number, account number, account type, and bank country | Preczn renders each input in its own iframe |
| Authorization checkbox and text | Hedgerow writes the text, records the customer's consent, and stores the record |
| Pay $485.00 | Hedgerow's button. It requests a single-use bank account token and sends it to Hedgerow's server. |
If a customer pays from a business account, collect the business name instead and send it as accountBusinessName. See ACH PaymentFields Integration.
Bank account payments need the customer's authorization before you debit the account. The text in this example is a placeholder. Confirm the wording you need with your processor. See ACH Best Practices and PaymentElements Integration.
Save a card for recurring service
In the example below, Hedgerow has decided to let homeowners sign up for weekly mowing in Cedar Hollow's client portal, which Hedgerow hosts. The customer pays for the first visit and saves the card, and Hedgerow charges it after each later visit.
Illustration only: a client portal page that Hedgerow designed. The highlighted card inputs are rendered by Preczn. Everything else is Hedgerow's.
| On screen | Who builds it |
|---|---|
| Plan name, price, and schedule | Hedgerow |
| First name, last name, and ZIP code | Hedgerow's own inputs. Hedgerow's server sends them with the transaction as firstName, lastName, and billingAddress.postal. |
| Card number, expiration, and security code | Preczn renders each input in its own iframe |
| Save this card checkbox | Hedgerow. When it's checked, Hedgerow's server adds ?tokenize=true to the first visit's sale. If the sale is approved, the response includes a multi-use token, and Hedgerow stores it. |
| Pay $65.00 and start service | Hedgerow's button. It requests a single-use token and sends it to Hedgerow's server, which creates the first sale. |
| The charge after each visit | Hedgerow's server sends a sale with the stored token and tokenUsage set to recurring |
Preczn returns a multi-use token only with an approved sale or auth, so the signup step charges the first visit. Preczn doesn't schedule charges. Hedgerow decides when to charge, and its server sends each sale. Multi-use tokens don't store the security code. See Tokenization and Card on File Flags.
Handle a card that needs verification
Some card issuers ask the cardholder to verify a payment before they approve it. This step is called 3D Secure. In the example below, Hedgerow has decided to support 3D Secure on its invoice payment page. When a homeowner's bank asks for verification, Hedgerow's page opens Preczn's verification lightbox over the invoice.
Illustration only: Hedgerow's invoice page with Preczn's verification lightbox open. The highlighted header is part of the lightbox Preczn renders. The bank screen inside it is a placeholder, because each card issuer designs its own.
| On screen | Who builds it |
|---|---|
| The invoice page behind the lightbox | Hedgerow. Its Pay button shows Verifying… while the lightbox is open. |
| Opening the lightbox | Hedgerow. Its server creates the sale. If the response includes authorization.threeDSecureChallenge with status CHALLENGE_REQUIRED, Hedgerow's page calls Preczn.ThreeDSecure.handleChallenge. |
| Dimmed background, panel, Secure Payment Verification header, and × button | Preczn. The panel is 600 by 444 pixels on larger screens and fills the screen on small ones. The header follows the customer's light or dark mode. |
| Bank name, purchase details, and code entry | The customer's card issuer. Riverstone Bank is fictional, and real screens vary by bank. |
| What happens after verification | Hedgerow. Preczn passes the result to Hedgerow's callback, and Hedgerow shows a confirmation or an error. If the customer selects ×, the callback receives a cancellation. |
3D Secure challenges are available on Stripe and Stripe Connect connections, for card payments that use a single-use token from PaymentElements or PaymentFields. See 3D Secure Integration.
Before you build
- Choose an integration. PaymentElements, PaymentFields, and the direct API differ in who renders the card inputs and where card data can appear. That choice affects your PCI scope. See Integrations, and confirm your SAQ type with your processors or your QSA.
- Keep transactions on your server. Browser code uses only your public API key, to get a token. Your server creates the transaction with your private key. See API Keys.
- Build with test keys. Test-mode tokens and transactions are invisible from live mode. See Live vs Test Mode.
FAQ
Does Preczn offer a hosted checkout page?
No. You build and host every checkout page. Preczn's browser SDKs render payment inputs inside your page. On Stripe and Stripe Connect connections, a 3D Secure challenge can also open in a Preczn-hosted lightbox when the issuer requires one.
Can I copy these designs?
The mockups are illustrations, not code. Preczn doesn't provide markup, styles, or design files for them. Design your checkout to fit your app, and use the integration guides for the parts Preczn renders.
Can the Preczn inputs match my brand?
Partly. You style the container around each input with your own CSS, and you set text styles inside it with configure(). See What you can style.
Related pages
Updated about 8 hours ago