Embedded Checkout Direct Post Integration Guide

Take full control of your payment experience with the Embedded Checkout Direct Post integration method. Build your own payment form and use our lightweight JavaScript library to securely submit payments directly to the Embedded Checkout API. This integration gives you maximum flexibility but requires that your client handles raw payment data, which increases your PCI compliance requirements. Consider using the Embedded Checkout Fields integration method for minimized PCI scope while maintaining flexibility.

Prerequisites

Before you begin, ensure you complete the following prerequisites. Once you create and save a checkout using the Checkout Designer in step 1 of this guide, your credentials will be available by navigating to the Embedded Checkout dashboard and selecting the checkout instance.

To get started quickly, clone the Embedded Checkout GitHub repository for sample code that sends the form to North from your site. You'll need:

• A North Developer account
• A checkout created using the Checkout Designer
• Your Private Embedded Checkout API Key
• Your Checkout ID
• Your Profile ID (your merchant profile identifier)

Migrating to Embedded Checkout

Existing North clients migrating to Embedded Checkout can use your existing North Developer login and Merchant IDs (MIDs). Contact Sales Engineering to make your MIDs available in your developer account so they can be assigned to an Embedded Checkout instance.

Transaction Types

Transactions completed with the Embedded Checkout Direct Post are Sales—meaning Auth and Capture are completed in one request. After the initial sale, a transaction token is returned in the response that can be used for subsequent payment functionality, such as voids, refunds, and reversals. Read the API Specification to learn more and contact us to discuss adding additional transaction types to your integration.

Quick Start

What You'll Build

Use this guide to build a completely custom payment form. You'll create and style your own payment input fields, and use our JavaScript library to securely submit payments directly to our payment API.

Checkout Flow

1. Create and save your checkout using the Checkout Designer, then copy your credentials from the Embedded Checkout dashboard.
2. Add the checkout.js script to your page.
3. For each payment attempt, create a checkout session on your server.
4. Build your own payment form
5. Submit the payment when your form is submitted using checkout.sendPayment()
6. Handle the payment response and verify completion via the session status endpoint.

Session Lifecycle and Statuses

A checkout session progresses through the following statuses. See step 6 in this guide for more details.

Step 1: Create Checkout and Get Credentials

Open the Checkout Designer while signed in to your North Developer account. Customize the way your Direct Post checkout looks and behaves including payment methods, receipt behavior, custom branding, and more.

When you save a new checkout or save updates to an existing draft, you are redirected to that checkout’s page in the Embedded Checkout dashboard. Your integration credentials are available there after a checkout is saved. Generate or copy your API key from that page.

• checkoutId — Checkout configuration identifier located toward the top of the page.
• profileId — Merchant profile identifier located toward the bottom of the page in the merchants list.
• Private API Key — Authenticates your server; click Generate Keys to display the API Keys modal for the first time. Afterward, click View API Key to view your existing key or create a new one. Store it only on the server and never in client-side code.
• Webhook signing secret — Used for webhook verification; located in the API Keys modal if you added a webhook domain when creating your checkout with the Checkout Designer.

Step 2: Create a Checkout Session

From your server, create a checkout session by calling the Create Session API endpoint and passing your private API key in the header as a bearer token. This request returns a short-lived token that authorizes payment submissions. Sessions expire after 30 minutes.

API Endpoint

Request Headers

Header
Value
Content-Type
application/json
Authorization
Bearer {YOUR_PRIVATE_API_KEY}

Request Body

Note: For Direct Post, the session locks in the amount it is authorized to charge. The payment submitted with sendPayment() must use this same amount.

Request Parameters

Example cURL Request

Response

Step 3: Add the Checkout Script

Include the checkout.js script on your page. This script provides the checkout object with the sendPayment() method.

Script Tag

Once loaded, the checkout object is available globally with the checkout.sendPayment(token, paymentRequest) method, enabling you to submit a payment directly.

Step 4: Build Your Payment Form

Create your own payment form with card input fields. You have complete control over the design and user experience.

Example Form

Step 5: Submit the Payment

When your form is submitted, build a payment request object and call checkout.sendPayment() to process the payment.

sendPayment Method Signature

Parameters

Payment Request Object

Payment Request Example

Step 6: Handle the Payment Response

The checkout.sendPayment() method returns the payment result directly from the payment processor.

Success Response

Declined Response

Response Handling Example

Server-Side Verification

Your server should never trust the client alone. When the user reaches your confirmation page (e.g., after a redirect), your backend must verify payment completion. There are two ways:

Method 1: Verify Payment Completion (Session Status Endpoint)

Endpoint: GET /api/sessions/status

Use this endpoint to verify whether a payment was approved or declined before fulfilling an order. The session status and payment response are stored at the server and cannot be tampered with by the client, so the status endpoint gives your backend a trusted source of truth.

Typical Flow

1. The user completes payment in your form (via checkout.sendPayment()).
2. The front-end redirects to your callback URL (e.g., a confirmation page), potentially passing the session token or payment data in the URL or via client-side state. Your backend must not trust that client-side data as a user could tamper with URL parameters or state.
3. When the user reaches your callback page, your backend calls the /status endpoint with the API key and session token, and receives the authoritative status and payment response from the server.
4. That response gives your backend a trusted source of truth for whether the payment was approved or declined and what the response was, which should be used to decide whether to fulfill the order.

Authentication

• API key in Authorization header as Bearer token
• Session token in SessionToken header

Request (API key + session token in header)

Note: The session token must not be sent from browser-based JavaScript. Use server-side code only to avoid exposing the session token. The status endpoint rejects requests with an Origin header.

Response (200 OK)

When status is Approved, body contains the full payment authorization response (receipt data). When status is Declined, body may contain the decline response.

Method 2: Transaction Webhook (Receipt)

Configure a webhook URL in your checkout using the Checkout Designer. When a payment completes, the API sends a POST request to your URL with the transaction and receipt data. The webhook URL must use HTTPS.

Note: You will need to provide this webhook URL for whitelisting during the certification process for Production notifications to be delivered to your endpoint.

Webhook Delivery

• URL: {webhookURL}/transaction
• Method: POST
• Content-Type: application/json

Request Headers

Request Body

• transaction – The transaction record. Includes id, tranType, authCode, authResponseText, authResp, authCardType, maskedAccountNumber, amount, authGuid, fullResponse, and other fields.
• additionalFormFields – (Optional) Custom form fields submitted with the checkout.

Verifying Webhook Signatures

Verify the X-YourApp-Signature-256 header using your checkout's private key:

Compare expected_header with X-YourApp-Signature-256. Reject the request if they do not match. Use the exact raw request body bytes you receive, not a re-stringified parsed object. JSON serialization can differ (key order, whitespace, etc.) and will break the signature check.

Signup Webhook

Each night, newly boarded merchants associated with your account are automatically added to your default checkout. When this occurs, the API sends a POST request to your webhook URL with the merchant data. Configure a webhook URL in your checkout using the Checkout Designer. The webhook URL must use HTTPS.

Webhook Delivery

• URL: {webhookURL}/signup
• Method: POST
• Content-Type: application/json

Request Headers

Request Body

The body is a JSON array containing one or more merchant signup objects:

Verifying Webhook Signatures

Verify the X-Webhook-Signature header using your webhook signing secret. The signing secret is prefixed with sec_ and can be created from your checkout instance page using the Generate Key or View API Key button.

1. Parse the signature header

The X-Webhook-Signature header contains a timestamp prefixed with t= and a signature prefixed with v1=, separated by a comma:

Extract the timestamp and signature values from the header.

2. Compute the expected signature

3. Compare signatures

Compare the computed hex digest with the v1 value from the header. Reject the request if they do not match. Use a timing-safe comparison function to prevent timing attacks.

Use the exact raw request body bytes you receive, not a re-stringified parsed object. JSON serialization can differ (key order, whitespace, etc.) and will break the signature check.

Step 7: Test the Integration

When a checkout is in Draft Mode, requests are automatically made in the Sandbox environment. When you're ready to go live and make requests in the Production environment, we'll certify your checkout with no need to manually switch environments.

In Draft Mode, requests are sent to the payment processor's Sandbox environment, guaranteeing that your tests receive real results from the processor, not mock responses, so that you can build accurate response handling into your application with confidence. To test various payment response codes in Draft Mode, the transaction amount can be modified to a designated value that will trigger a specific response code. Read more about response code triggers.

UI/UX testing can also be done from the Checkout Designer using the integrated card testing tools, however these are mock payment requests that do not return real results from the payment processor.

Use the following test card numbers in the Sandbox environment:

Test Card Details:

• Expiration: Any future date in MMYY format (e.g., "1225")
• CVV: Any 3 digits (e.g., "123") or 4 digits for Amex
• ZIP: Any 5 digits (e.g., "12345")

Apple Pay

Embedded Checkout supports Apple Pay as an alternative payment method. The sections below describe what is needed to enable Apple Pay on your domain when using Embedded Checkout Direct Post. Because your payment page and checkout script run on your domain, there are specific requirements that you as the integrator must fulfill.

How It Works

Apple Pay on the web requires that every domain displaying the Apple Pay button is registered and verified with Apple. Since Embedded Checkout Direct Post runs on your domain, Apple requires your domain to be verified. As a platform integrator, we handle the registration of our own checkout domain. Your responsibility is to register your domain(s) where your payment flow is hosted.

Requirements

To enable Apple Pay on your domain, complete two steps:

Step 1: Host the domain verification file

Apple verifies domain ownership by checking for a specific file on your domain. You must host the following file at this exact path on your website:

File contents

Copy the following hex string exactly as-is into the file. Do not decode, modify, or re-encode it:

The file must be served as plain text with no authentication, redirects, or bot protection blocking it. Apple will fetch this file to verify your domain. If Apple cannot access it (e.g., due to a WAF, CDN challenge page, or 403 error), domain registration will fail.

To verify the file is accessible, run:

You should see the hex string returned with no HTML wrappers or redirect responses.

Step 2: Register your domain

Once the verification file is hosted and publicly accessible, navigate to Embedded Checkouts on your dashboard and select a checkout instance to reach the checkout management page, then click Register Domain with Apple Pay. This will trigger the domain registration process with Apple on your behalf. This calls Apple’s registerMerchant API using our platform integrator credentials and registers your domain against our Platform Integrator ID. You do not need your own Apple Developer account or merchant ID to complete this step.

What happens during registration

Troubleshooting

Google Pay

Embedded Checkout supports Google Pay™ as an alternative payment method. The sections below describe what is needed to enable Google Pay on your domain when using Embedded Checkout Direct Post.

When offering Google Pay to your customers, you must use the official Google Pay logo and button assets in compliance with the Google Pay Web Brand Guidelines, without modifying the asset colors, proportions, or appearance. The button rendered by the Direct Post checkout experience is created by Google's official JavaScript client library and is already compliant.

How It Works

As a payment service provider (PSP), we handle the Google Pay integration centrally. Individual merchants using our Embedded Checkout do not need to register individually with Google for Google Pay — our PSP registration with Google covers all merchants using Embedded Checkout.

Because Embedded Checkout Direct Post is a hosted integration, our checkout generates the IsReadyToPayRequest and PaymentDataRequest objects on your behalf, loads the Google Pay JavaScript client library, renders the compliant Google Pay button, and handles the returned payment token server-side. You do not need to call Google's APIs directly.

By enabling Google Pay on your checkout, you and your merchants agree to the Google Pay and Wallet API Acceptable Use Policy and the terms defined in the Google Pay API Terms of Service.

Reference Documentation

If you want to learn more about how Google Pay works on the web, refer to the resources below. Most integrators will not need these — the embedded checkout handles the full web integration — but they are useful for understanding the underlying flow and for fulfilling brand requirements.

• Google Pay Web developer documentation
• Google Pay Web integration checklist
• Google Pay Web Brand Guidelines
• Google Pay and Wallet API Acceptable Use Policy
• Google Pay API Terms of Service

Requirements for Integrators

There is no domain verification or file hosting required for Google Pay. The Google Pay button and payment flow are handled within the Embedded Checkout experience when wallet methods are enabled for your checkout.

To enable Google Pay on your checkout, ensure the following:

1. HTTPS required — Your domain must serve the page containing your payment form and checkout script over HTTPS. Google Pay will not function on insecure (HTTP) pages.

2. Browser compatibility — Google Pay on the web works across Chrome, Safari, Firefox, and other modern Chromium-based browsers. The button will only render for users whose browser and device combination is eligible and who have at least one supported payment method saved to their Google account.

3. Payment configuration — When setting up your checkout, ensure that Google Pay is enabled in your payment configuration. The checkout will automatically display the Google Pay button to users who have eligible payment methods saved to their Google account. Use the Checkout Designer to configure payment methods.

4. Acceptable use — Your use of Google Pay through Embedded Checkout is subject to the Google Pay and Wallet API Acceptable Use Policy and the Google Pay API Terms of Service.

Supported Authorization Methods

Google Pay provides two authorization methods. Embedded Checkout supports both.

Settlement is currently supported in the United States (USD).

Supported Card Networks

Embedded Checkout supports the following card networks through Google Pay:

• VISA
• MASTERCARD
• AMEX
• DISCOVER
• JCB
• INTERAC

The card networks offered to a customer at runtime are also constrained by the networks enabled on your North merchant account.

Gateway Configuration

When Embedded Checkout builds the Google Pay PaymentDataRequest, it sets the following TokenizationSpecification:

• gateway is fixed to north — this is the gateway identifier we registered with Google during technical onboarding.
• gatewayMerchantId is set to the unique identifier of your checkout configuration (the checkout ID visible in your Embedded Checkouts dashboard). Do not change this value — it is what we use to route the decrypted payload to the correct merchant account.

Separately, in PRODUCTION the Google Pay PaymentDataRequest includes a merchantInfo.merchantId value — this is North's PSP-level Google Wallet Console merchant ID. It is shared across all checkouts using Embedded Checkout and is managed by the platform. Merchants do not need to register individually with the Google Pay & Wallet Console.

Because the checkout owns the Google Pay request, you do not need to set any of these values yourself. They are shown here for transparency and so that you can verify them with your browser's developer tools if needed.

Billing Address

By default, Embedded Checkout does not request a billing address from Google Pay (billingAddressRequired is not set on the Google Pay request). If your checkout form collects billing address fields separately (for AVS purposes), those are gathered through the posted form rather than through Google Pay. If you need billing address data to be pulled from the user's Google account instead, contact your North integration engineer.

What the Customer Sees

When the customer taps the Google Pay button, the Google Pay sheet displays:

• The total price, labeled "Total", in USD.
• The customer's eligible cards and the option to pick another card.

Handling the Google Pay Payload

Merchants do not send the Google Pay encrypted payload to their own servers. Embedded Checkout performs the full token handoff for you:

1. The customer taps the Google Pay button rendered by the checkout.
2. Google returns a PaymentData response containing the encrypted paymentMethodData.tokenizationData.token. Because Embedded Checkout sets emailRequired: true, the response also includes the customer's Google-account email, which is forwarded to our Checkout API alongside the token for use in receipts, webhooks, and transaction metadata.
3. The checkout sends the token to our Checkout API at POST /api/google-pay along with the session token issued for the checkout.
4. Our Google Pay decryption service verifies the signature against Google's signing keys (using the ECv2 protocol and the gateway:north recipient ID) and decrypts the payload.
5. The decrypted card credentials — including the network cryptogram (tavv) and ECI indicator (tavv_eci) for CRYPTOGRAM_3DS tokens — are submitted to the configured payment gateway to authorize the charge.
6. The transaction result is posted back to your configured return URL (and to your configured webhook, if any).

As an integrator you do not need to implement token decryption, manage signing keys, or call Google's APIs directly.

Google Pay Environment

In the Sandbox environment, Google Pay returns simulated card data. You can use this to verify your end-to-end checkout flow without processing real payments.

Additional Notes

Success Checklist

Before submitting your checkout for review and certification, verify the following:

• Session tokens are created successfully
• Test card transactions are approved
• Declined transactions show proper error messages
• Card number formatting is handled correctly
• Expiration date is converted to MMYY format
• Amount validation works (positive numbers only)
• Webhook or session status endpoint receives transaction notifications
• Error states are handled gracefully
• If you offer Apple Pay or Google Pay, complete the checks in Apple Pay and Google Pay (domain file, dashboard registration, HTTPS, and payment-method configuration as applicable)

Protect Your API Keys

• Never expose your private API key in client-side code
• Store API keys in environment variables
• Generate session tokens only on your server

PCI Compliance

Direct Post integration requires handling raw card data, which increases your PCI scope to SAQ A-EP. Ensure your implementation meets all PCI DSS requirements .

• Use HTTPS for all pages handling card data
• Never log or store raw credit card, payment, or transaction data that's protected under PCI DSS requirements
• Implement proper input validation
• Consider using the Embedded Checkout Fields integration to reduce PCI scope

Domain Restriction

In the Production environment, the domain where your checkout is hosted is limited to the domain set during checkout configuration. This prevents unauthorized use of your checkout configuration. This rule is not applied in Draft Mode.

For draft checkouts, we disable the frame-ancestors directive in the Content-Security-Policy (CSP) on hosted checkout responses. That supports development and testing from flexible origins such as localhost, preview deployments, or staging URLs. After publish to Production, frame-ancestors is enforced from your configured allowed domains, so those domains must include every parent page or embedding context where North-hosted checkout UI is used.

When testing in Sandbox, set the checkout domain in the Checkout Designer to your test site's URL (include a non-default port if you use one). Sandbox payments are still test-only; this just keeps the checkout configuration aligned with where you integrate before publish.

Session Token Expiration

Session tokens expire after 30 minutes. Generate a new token for each checkout session rather than reusing tokens.

Error Handling Best Practices

Next Steps

• Contact Support — Get help with your integration.
• Certify and Go Live — When development is complete, use the Request Publish button on a checkout instance to submit the checkout for review by Sales Engineering and begin the certification process. You can keep using the same dashboard-issued credentials after certification is complete and your checkout is published to the Production environment.
• Manage MIDs — Each checkout instance can be used by one or more Merchant IDs (MIDs). Open a checkout and use the Add Merchants button to assign the MIDs that should use this configuration. Only MIDs that are successfully onboarded to North and provisioned for your organization appear in the search results. If a MID is missing, ensure merchant onboarding is complete or ask your North contact to link it to your account.