Skip to main content
View all customer transactions, inspect payment details, process refunds, and more in your FunnelFox Payments dashboard.

View payments

You can view all payments in your organization as well as all payments for a specific customer:
  1. Go to the Payments page of your FunnelFox Payments dashboard. To narrow the list, fill in filters such as Order ID, Email, or Status, and click Apply filters.
  2. To see one customer’s payments, find the customer with the search box at the top of the dashboard and open their page. The Payments block shows their latest payments. If they have more, click View all.
  1. Click any payment to open its Payment Details page.
The list includes all subscription payments, as well as one-offs.

Payment details

The Payment Details page shows the order ID under the page title and the total amount charged to the customer at the top. Below, you see:
  • Payment Method: Card details including masked number, expiration date, card type, and issuer country.
  • Price Point: The product and price purchased, shown in Order details with its pp_ident.
  • Primer: The internal payment identifier (pop_payment_id), shown in Order details. It links to the payment in Primer.
  • Initiated by: Shows whether this is a Customer Initiated Transaction (CIT) or a Merchant Initiated Transaction (MIT). It shows CIT for every one-click payment. To see how a one-click payment was sent, check initiation_type in Order meta.
  • Order meta: JSON object containing payment context like iteration number, subscription ID, and payment type. Click it to expand. For a one-click payment, it also holds initiation_type (cit or mit), and threeds_challenged when the customer got a 3DS challenge. A one-click payment through Primer can also hold threeds_outcome, threeds_reason_code, saved_method_type, and card_network. Learn more in One-click payment webhooks.
The Transactions card lists each PSP transaction of the order:
  • PSP transaction ID: Payment processor’s unique transaction identifier, shown with its status (authorized, settled, etc.).
  • Transaction ID: The internal identifier FunnelFox Payments assigns to the transaction.
  • PSP merchant ID: Merchant account identifier used for this transaction.
  • Amount: Transaction amount and type.
  • Transaction date: When the PSP processed this transaction.
  • Created: When FunnelFox Payments recorded this transaction.
A single order may have multiple PSP transactions as it moves through authorization and settlement stages.

Manage payments

FunnelFox Payments allows you to refund any payment or process one-click purchases (like upsells) using securely stored payment credentials.

Refunds

To ensure refunds are processed correctly, initiate them only through the FunnelFox Payments dashboard, Primer, or the FunnelFox Payments API. To process a refund in the dashboard:
  1. Open the payment from the Payments page or from the customer’s page.
  2. Click Refund at the top right. The button appears only for settled payments that still have an amount left to refund.
  1. Configure your refund in the Refund payment dialog:
  • Amount: Leave it empty to refund everything still refundable.
    • If the entire amount is refunded (full refund), the subscription immediately becomes EXPIRED and the one-off payment is revoked.
    • If a partial amount is refunded, auto-renewal is disabled automatically.
  • Reason: Required. Select a reason, such as Customer request or Duplicate payment.
  • Comment: Optional context for the audit log.
  • Soft refund: Refunds the payment but keeps auto-renewal enabled. The subscription or one-off remains active.
  1. Click Process refund.
You can also refund a subscription payment from the Payments block on the subscription’s page.
Refunds are limited to 50 attempts per day per organization, and this limit is configurable per merchant.

One-click payment

Once a customer completes a purchase, their payment credentials are securely stored. This allows one-click payments for both one-off and subscription upsells without re-entering details. You can perform one-click payments from the FunnelFox Payments dashboard or using the FunnelFox Payments API.
One-click payments have their own rate limit, separate from renewals: 5 attempts per saved payment method per hour by default. Change it with one_click_limit in Settings.
To process a one-click payment in the dashboard:
  1. Find the customer with the search box at the top of the dashboard and open their page.
  2. Click Charge customer at the top right. The button appears only when the customer has a saved payment method.
  1. Select the price point to upsell under Price point.
  2. Click Charge.

Customer-initiated (CIT) payments

One-click payments go as by default. You can send them as instead, and the bank may then ask the customer for 3DS. CIT works only for cards saved through Primer: Apple Pay, Google Pay, PayPal, and Charge customer payments always go as MIT. To send one-click payments as CIT:
  1. Go to Settings > Main in the FunnelFox Payments dashboard.
  2. Set the New Value of one of these settings:
    • one_click_initiation: For the whole organization, for example {"mode":"cit","cit_card_networks":["VISA"]}. An empty cit_card_networks list allows all card brands.
    • funnel_one_click_initiation_overrides: For specific funnels, keyed by funnel ID. A field you leave out keeps the organization value.
  1. Click Save, then confirm the change.
From a browser, a funnel’s override applies in full only if the customer’s first purchase was in that funnel with the same payment method.
A payment that needs 3DS stays pending until the customer completes it. Turn on CIT only for funnels whose upsell page handles 3DS.

One-click payment webhooks

Every order webhook of a one-click payment carries an order.one_click object. It shows how the payment was sent, which saved method was charged, and how 3DS went. For every other order, order.one_click is null.
  • initiation_type: cit or mit, as the payment was sent to the PSP.
  • threeds_outcome: The 3DS outcome of this payment, for example none, frictionless, or challenge_passed.
  • threeds_reason_code: The PSP’s raw 3DS reason code, for example CARD_AUTHENTICATION_FAILED. It’s null when the PSP reports none.
  • saved_method_type: The saved method that was charged: card, google_pay_pan_only, google_pay_device_token, google_pay_unknown, apple_pay, paypal, or other.
  • card_network: The card brand in upper case, for example VISA.
  • threeds_required: true unless threeds_outcome is none or skipped.
threeds_outcome, threeds_reason_code, saved_method_type, and card_network are filled only for Primer integrations. They are null for other PSPs and for orders created before these fields were added.
  • none: No 3DS ran.
  • pending: The customer got a 3DS challenge and no result has come back yet.
  • frictionless: The bank authenticated the customer without a challenge.
  • challenge_passed: The customer passed the challenge.
  • challenge_failed: The customer failed the challenge.
  • frictionless_failed: The bank rejected the authentication without a challenge.
  • abandoned: The customer didn’t complete the challenge. The PSP reported a timeout at the bank or that the customer didn’t perform the authentication.
  • skipped: 3DS wasn’t available, or an exemption was accepted.
  • completed_unknown: The customer got a challenge and the payment succeeded, but the PSP reported no 3DS result.
  • failed_without_result: The customer got a challenge and the payment was then declined, failed, or was cancelled, but the PSP reported no 3DS result. A failed challenge can’t be told apart from an abandoned one.
No order webhook is sent while a payment waits for 3DS. So if the customer never completes the challenge, no webhook reports it as abandoned. See the full payload in the webhook reference.

Idempotency

When you call the one-click API from your own code, send an idempotency_key with each purchase attempt. A retry with the same key charges nothing and returns the original order with idempotent_replay: true. Generate one key per purchase attempt and reuse it on every retry, because a new key always creates a new charge. Keys are unique per customer and shared with custom charges. A key already used for another Price Point or a custom charge returns idempotency_key_reused. If the PSP no longer accepts the customer’s saved payment method, the request fails with HTTP 400 and the saved_payment_method_rejected code. Nothing is charged. Ask the customer to enter their card details again.

Payment method update

Customers may experience failed payment attempts due to issues with their payment method. FunnelFox Payments lets you redirect customers to the Update payment method page where they can provide a valid payment method. To activate this feature, contact your Solution manager.

Metadata

FunnelFox Payments attaches metadata to every payment request sent to Primer:
By default, FunnelFox Payments includes the customer’s email in the metadata. If the email entered is not valid, it is skipped automatically. An email is valid only if it passes all of the following validation rules:
  • Must be a properly formatted email address (has a local part, an @ sign, and a valid domain).
  • Reject if the email ends with example@example.com.
  • Reject if the email starts with FIXME@.
You can also disable sending email in metadata entirely:
  1. Go to Settings > Main in your FunnelFox Payments dashboard.
  2. Find the include_email_into_primer_request setting and set its New Value to Disabled.
  3. Click Save, then confirm the change.

Billing descriptor

The billing descriptor is the short text FunnelFox Payments sends with a charge, which the bank prints next to the amount on your customer’s card statement. It is also the label shown in the Apple Pay recurring payment sheet. Use a name customers recognize, such as your app or brand rather than your legal entity, for example ACME.COM. A recognizable descriptor reduces disputes opened for unrecognized charges. You can set the descriptor in two places: Where you change the descriptor decides who sees the new text: A descriptor accepts up to 22 characters: letters, digits, spaces, and . , _ ? + / -. Other characters, including apostrophes and &, are rejected and block saving. Once set, FunnelFox Payments sends the descriptor to Primer and to Stripe, where it is the suffix appended to your Stripe account’s own prefix. Adyen, PayPal, Braintree, Checkout.com, and Airwallex take statement text from their own account configuration, so set it there.
Saving a price point with an empty Descriptor stores the current organization default into that price point, so it no longer follows later changes to the default. A price point stays genuinely empty only if it was saved while the organization default was also empty.

Email

When a customer purchases a subscription, FunnelFox Payments stores their email if it was collected in the funnel. To view it:
  1. Find the customer with the search box at the top of the dashboard and open their page.
  2. The email appears in the Customer card, under Email.
You can also collect email automatically from Apple Pay at checkout, without requiring a manual input in the funnel:
  1. Go to Settings > Main in your FunnelFox Payments dashboard.
  2. Find the collect_apple_pay_email setting and set its New Value to Enabled.
  3. Click Save, then confirm the change.
Learn how to update customer emails stored in FunnelFox Payments.
Once enabled:
  • If email is collected both from a funnel input and from Apple Pay, the Apple Pay email takes priority.
  • The system keeps both addresses: the secondary email is stored as an alias.
  • When an Apple Pay email is captured, a user webhook fires with the update_email subtype.
  • The Apple Pay email is not included in payment metadata. It is available directly in FunnelFox Payments.
This ensures you always have a valid email for your customers, even if they enter a placeholder email in the funnel.

Next steps