# Payments Alunta can register manual payments and connect your team's own account with supported payment providers. Which providers are available is a team setting. ## When a card is charged Alunta attempts card charges three times daily at 00, 08, and 16 in the team's timezone. A period becomes chargeable on its first day, and a first partial period billed with the next renewal on that renewal. A usage-based period becomes chargeable the day after it ends because usage is only known then. The charge happens before the invoice is created. When automatic card charging is off, card subscriptions appear in the manual invoicing prompt. Confirming the prompt charges the card and creates the invoice. A subscription covered by a payer is settled through the payer's consolidated invoice, and a period reduced to zero by a discount needs no payment. ## Stripe SEPA Direct Debit When your team uses Stripe, customers can save a SEPA Direct Debit bank payment method through the public API, checkout or customer portal. Hosted flows offer SEPA when the connected Stripe account enables it and the payment is in EUR. There is no additional Alunta switch. An integrator can keep its own Stripe Elements and successful off-session SetupIntent flow and attach only the resulting PaymentMethod reference through the same API used for cards. SEPA needs an active reusable mandate and can only collect EUR. The saved method shows safe last four digits and bank country, with no card expiry. A revoked or detached mandate cannot collect a new payment. It is skipped when choosing a method for a non-EUR subscription; an explicit incompatible choice is rejected. Debits use the normal Stripe collection schedule and failure rules, without card preauthorization. A submitted debit can be under processing for several business days. No payment or paid invoice is recorded until Stripe confirms success, and an unresolved attempt is not charged again. A purchase or paid resumption completes only after that confirmation. For a paid quantity upgrade, the extra capacity becomes available only after confirmed collection. Stripe collects consent and sends its default debit notifications. SEPA payments use the existing Stripe clearing account configured for card payments. Refunds may remain pending. Bank returns follow the Stripe dispute/chargeback flow below, which reopens the invoice without automatically charging again or cancelling the subscription. ## When a payment fails - **Do nothing.** The failure is recorded and the subscription continues. - **Notify customer of failed payment.** The customer receives follow-up after 3 and 7 days when automatic card follow-up is enabled in Payment reminders. This setting never cancels the subscription. - **Cancel immediately.** The subscription ends under the rules for protected periods. - **Retry then cancel.** Alunta retries until the applicable deadline, normally seven days after the day the failing period became chargeable (its first day; for a usage-based period the day after it ends; for a period invoiced on its last day, its last day; for a first partial period billed with the next renewal, that renewal) or, for an installment, after the billing date of the failing slice. These rules apply to charges Alunta makes on its own. When automatic card charging is switched off, Alunta neither charges nor retries the card: the team charges it from the invoice action, and a decline there does not trigger the rule, so it never notifies the customer or cancels the subscription. A decline Stripe reports later (for example for SEPA Direct Debit) still follows the rule. After a genuine decline, Alunta waits 24 hours before automatically trying the same card again, whichever period, installment slice or bundle one-off payment the attempt was for, and the charge run sends at most one period or installment charge per run to a card declined since its last successful charge. Once the card (or SEPA mandate) has been declined 8 times in a row, with no successful charge in between, Alunta stops automatic attempts on it, including preauthorizations, and the dashboard lists the customer under "Automatic card attempts have stopped". Attempts resume when the customer adds a new card or a charge on the card succeeds. A preauthorization on a stopped card is not captured and lapses. With "Retry then cancel" a stopped card is tried again, at most once a day, once the deadline is reached, so the subscription can be cancelled if that attempt fails too. A manual retry from the app remains possible, also on a stopped card; if it fails, it counts towards the 8 and starts the wait. The charge run waits up to 24 hours before trying again, including after the customer replaces the card, so `awaiting_charge_run` can mean "after that wait". On a stopped card, `awaiting_charge_run` can also cover a charge that is only attempted once the customer adds a new card. What happens next follows the plan rule that applied when the period was created. When Alunta charges a saved card on its own and the card's bank requires the customer to authenticate (for example 3D Secure), the charge cannot be completed without the customer. Alunta no longer leaves such a payment pending: it cancels the attempt and treats it as a failed payment, so the failed-payment action you have chosen runs and the customer is asked to update the card. A checkout or resume where the customer is present and completing authentication stays pending until the customer finishes. An ordinary paid or invoiced period is protected during cancellation, so the customer normally keeps the period already paid for. For installments, each unpaid, due slice is evaluated separately; a settled slice is not made unpaid, while a future slice alone is not a reason to cancel the whole subscription. When a failed payment ends the subscription, the service runs through the last period that is paid in full. An installment period counts as paid in full only when every one of its slices is settled. If a slice of the installment period running today has been paid, the service runs until the failure date instead; with neither, the end date is the failure date. An older, finished installment period with only some slices paid does not extend the service. The unpaid slices of a partly paid period are not deleted, but they are no longer collected while the subscription is ended by a failed payment: they are not charged, not invoiced and not shown as outstanding, and the period does not count as paid in full. This also holds for a team with manual card capture, when a new card is linked, and when the subscription is cancelled again with the same or an earlier end date: the failed payment is still the reason it ended. If the end date is moved later instead, the team is letting the subscription run on: the reason it chose then replaces the failed payment, and the subscription is collected again for the period it now runs and can have a new card linked. Whole periods with no payment are deleted, as they always were; an unpaid whole period that a later paid period has locked stays but is likewise neither charged nor invoiced. Periods that are already paid are still invoiced. If the subscription is resumed, the unpaid amounts are collected again. The slices that are already paid are still invoiced, and the card that would collect the rest is removed. An unpaid amount that is not collected is shown in the app as "Not collected" (the subscription was ended by a failed payment), not as a payment waiting to be charged, and it is not listed under "Requires action". If the ended subscription is transferred to another customer, the previous customer's unpaid amounts are not invoiced to the new customer; periods that are already paid are still invoiced. The customer cannot resume the subscription online with a card payment while an installment period running today is already partly paid: no payment is created and the customer is asked to contact the company. An expired card alone does not prove that an earlier attempt failed. For installments, the individual unpaid, due slice is evaluated. Follow a pending payment before choosing cancellation. ## A payment status must be confirmed A planned date or authorization is not a completed payment. The payment is shown as completed only after the provider confirms the result. For a declined or pending status, follow the action shown and do not send a payment receipt. When paying an existing invoice through a Stripe payment link, some payment methods enabled by the team can remain pending for several days. Alunta records the payment only after Stripe confirms it. While the payment is unresolved, the link does not open a new payment attempt. Once Stripe confirms a decline with no money received, the end customer can try again through the invoice payment link. Reusable SEPA methods can also be saved for EUR subscriptions. ## Refunds and credit notes A refund, local reversal, and chargeback are different money flows. The normal credit flow can produce a credit note, while a reversed payment does not necessarily do so. Read the refund amount and type, and treat a requested refund as pending until completed. Webhooks may be delivered more than once, so an integration should recognize the same refund. If you use the public invoice webhook, `invoice.refunded` includes `data.refund.kind` (`provider_refund`, `local_reversal`, or `chargeback`), `data.refund.amount`, `data.refund.uuid`, and `data.refund.original_invoice_uuid`. Use the refund UUID as your idempotency key so a repeated webhook is not booked twice. Keep the credit note separate from the original invoice: the credit note is the document, while the refund describes the money flow. `chargeback` covers both Leverandørservice chargebacks and Stripe disputes where Stripe withdrew the funds; it keeps the original payment and refers to the original invoice, and no credit note is created. `invoice.paid` means a payment covered the full outstanding balance. A partial payment does not emit it; it fires on the first transition to a fully covered balance, including when the resulting status is overpaid or credited because a related credit note exists. The credited original invoice and the credit note remain separate documents. ## Stripe disputes When a customer disputes a Stripe payment (card or SEPA), Stripe can withdraw the money from your Stripe account when the dispute is opened. SEPA disputes are final and cannot be challenged; card disputes may be reviewed. Alunta reacts in steps: - **Dispute opened.** Alunta only notifies your team ("Payment disputed") so you can respond in Stripe before the deadline for a card dispute. For SEPA, follow up directly with the customer. This notification does not itself record a movement of money, and Alunta never answers or accepts a dispute on your behalf. - **Funds withdrawn.** Alunta records a chargeback against the payment (the payment shows "Charged back") and the invoice is open again for the disputed amount; a partly disputed payment reopens only that part, and Alunta never charges back more than the payment still holds after earlier refunds. Your team gets a notification and an entry under the Stripe integration errors ("Stripe withdrew funds for a payment dispute"). If your team uses payment reminders, the reopened invoice is reminded only under your normal reminder rules; the dispute does not trigger a special reminder. - **No automatic follow-up.** Alunta does not charge the customer again, does not cancel the subscription and does not send the customer a payment-failed email. The subscription keeps running and you decide how to follow up with the customer. - **Card dispute won.** Stripe returns the funds and Alunta records the payment again as a new payment on the same invoice. The invoice is paid again, the payment is synchronized to accounting like any other payment (in Billy, where Alunta does not book the chargeback automatically, you book the returned payment by hand as well), and your team gets a "Dispute won" notification. The original payment and its chargeback stay as history. Alunta books back at most the amount that was charged back. If you want to refund the customer after winning, do it through Alunta as usual: the returned payment is an ordinary payment on the invoice. A payment that is not yet linked to an invoice (for example a renewal charged before the invoicing run) cannot be reversed yet. Alunta keeps retrying automatically, and an hourly check covers disputes from the last 420 days. Only disputes where Stripe withdrew the funds on or after 7 October 2026 are recorded; earlier disputes are not imported, because teams already handled those themselves. If the team has accounting sync for payments turned on, a chargeback is also booked as a reversal in the accounting system; see the accounting guide. Through the API a Stripe dispute is reported as `invoice.refunded` with `data.refund.kind` `chargeback`, never as `invoice.payment_failed` or `subscription.payment_failed`. ## Replace a card after a failed charge When the customer portal shows **Update card** for a subscription with a failed payment, the customer can choose a saved card or add a new one. Changing the card does not charge money by itself. The portal continues to show the next step if the new card has not yet been attached to the subscription, and a new charge follows the displayed attempt. The default card for new purchases and the card on an existing subscription are separate choices, so check which card was actually changed. ## What your AI can see about card payments The card payment tools only appear once the team has a connected card provider (Stripe, QuickPay, OnPay, PensoPay or Cost+) or subscriptions that are paid by card. When an app or an opt-in is switched on, the AI client must reconnect or reload its tool list to see them. Your own AI can see card payments at two levels. At the aggregate level (`get_card_payment_overview`) it can see how many card subscriptions have an outstanding payment right now and what state they are in, the amount due per currency, the split by provider and by payment-failure policy, how many will be ended automatically within 7 days, how many failed attempts there were in a period (the end date may be at most 366 days after the start date), and how many subscriptions have an expired card or a card that expires this month or next month (subscriptions that a reseller pays for are not counted, because they are never charged on their own card). At the detail level (`list_card_payment_issues`) it can see the individual subscriptions with customer, plan, provider, state, amount, due date, latest failure reason, payment-failure policy, days until cancellation, and the card's brand and expiry month. The detail level requires both Customer details and Payment and bookkeeping details to be switched on under "What AI can see". An outstanding payment is a billing period - or a due, unpaid installment slice, when the period is paid in installments - that the automatic card charge should have collected by now but has not. It is the rule that gives a subscription the "Payment failed" status in the app, and it covers both whole periods and slices. The customer portal uses the same rule for the customer's own subscriptions but does not show cancelled subscriptions, so the final period of a subscription that has just ended is seen only in the app and by the AI. The app therefore shows "Payment failed" for every outstanding payment, including one that has not been attempted yet, while the AI's `failed` state separates a confirmed failure from the rest. A period is due once it has started (a usage-based period once it has ended; a period invoiced on its last day, from that day; a first partial period billed with the next renewal, from that renewal), by the charge's own calendar day. A slice is due once its billing date has arrived, the slice itself is neither paid nor invoiced, and its period has not been charged or invoiced as a whole. Pause and trial periods, periods with nothing to charge after a discount or without usage, periods outside the subscription's billing period, periods waiting for a plan change, and subscriptions that a reseller pays for are not counted. The final period of a subscription that has just ended still counts while it is inside the billing period. Failed attempts on deleted subscriptions still count in the number of failed attempts and in the split by reason, but deleted subscriptions are not part of the number of subscriptions affected or of the outcomes. "Outstanding" means due and unpaid - not necessarily something the next charge attempts right now: the charge skips a period or an installment slice for a day after a failed attempt, for example. Each outstanding payment has a state: `processing` (an attempt is in flight and money may already be moving), `uncertain` (a payment was taken but is not linked to the period or slice, or an attempt has an unresolved outcome - for example a failed attempt the provider did not confirm, an unclear response or a reservation that has not been released - so money may already have moved), `failed` (the provider confirmed a failed or expired attempt on the subscription's current card - a subscription without a card is never `failed`), and for payments that were never attempted the reason nothing is collecting them: `no_usable_card` (the subscription has no card of its own, the card was deleted or belongs to another customer, or the card has expired so the charge would fail), `automatic_charging_off` (the team has switched automatic card charging off or has no invoicing settings, or QuickPay charging is temporarily paused for the team), `provider_disconnected` or `awaiting_charge_run` (the next charge will collect it, for example because it only became due today). Attempts that belong to another team, customer or provider than the subscription's are ignored. Only `failed` is a failed payment. The amount is the outstanding amount per currency, including payments the charge cannot take right now (for example because there is no usable card), calculated the way the charge would (price after discount plus VAT, combined per card; a slice is charged on its own), and for `processing` and `uncertain` the money may already have moved. The number of subscriptions per state or per policy can add up to more than the total number of outstanding subscriptions when one subscription has both a period and a slice outstanding; the rows (items) reconcile exactly with the list. Days until cancellation and the count of cancellations within 7 days only apply to rows in the `failed` state on subscriptions with the "Retry then cancel" policy, because Alunta only ends a subscription after a failed charge: the number is the days left of the retry window, counted from the day the row's earliest due charge fell due or, for a slice, from that slice's billing date, under the policy recorded on that period. For a payment that is in flight, unresolved or never attempted, for every other policy, and for a failed payment that the charge run will not retry (automatic card charging is switched off or the team has no invoicing settings, QuickPay charging is paused for the team, or the card provider is not connected, so nothing would end the subscription), there is no number and the row is not counted. Two more things must be kept apart. A failed attempt that is no longer outstanding is called resolved, not paid: the customer may have paid, switched card or payment method, or the period may have been cleared in some other way. And an expired or soon-to-expire card is not a payment failure by itself. A card's expiry month and the due dates follow the timezone the charge itself uses. AI never sees the card's last four digits, card or payment tokens, the providers' internal ids or the provider's own error text, and never the customer's contact details in these answers. Every scan of rows is bounded; when there are too many, the tool returns an error instead of a partial answer. ## Leverandørservice Leverandørservice has its own mandate and banking schedule. The customer needs an active mandate, and a submitted collection is not received money. The invoice can therefore remain unpaid longer than for a card payment. ## Manual payments A manual payment can be registered on an invoice with an outstanding balance, for example after a bank transfer. Credit notes and invoices without a remainder cannot receive a manual payment. A smaller payment leaves the invoice partially paid; it becomes paid only when the balance is covered. ## When Alunta shows an invoice as unpaid Alunta only marks an invoice "Not paid" or "Overdue" when Alunta can actually see whether it was paid: Alunta collects the payment itself (card, MobilePay, or Leverandørservice), the team has turned on "We record payments in Alunta" for bank-transfer invoices, or Alunta imports settled payments from a connected e-conomic, Billy or Dinero account with payment import turned on (booked DKK invoices only, and only payments the provider reports in a form Alunta can match to the invoice). Payment import is an opt-in per connection and stays off until the team turns it on; in Dinero the setting is "Record payments automatically" under "Import payments from Dinero". For every other invoice - for example a bank-transfer invoice a team only reconciles in an e-conomic, Billy or Dinero connection without payment import turned on - Alunta shows no payment status. That applies only in the app: the invoice list shows the invoice without a payment status, and the customer's "Unpaid invoice" badge, the "Overdue invoices" filter and the "Outstanding invoices" dashboard widget leave it out, because Alunta cannot back up the "unpaid"/"overdue" claim. The invoice's own status and outstanding balance in the public API are unchanged. The MCP tools count them in, instead. get_overdue_summary includes them in overdue_invoice_count and reports the count in payment_status_tracking.unknown_payment_status_invoice_count; list_overdue_invoices returns them with payment_status_known: false. Never describe these invoices as unpaid, and do not suggest reminders for them without checking the accounting system first. ## Payment status and follow-up A payment can be planned, declined, pending, completed, or reversed. Use the status on the specific payment together with the invoice. A payment-failed webhook can recur on a later attempt; a later paid webhook is not the same as the earlier failure. A subscription that eventually ends has its own subscription status. When a card expires, look for unresolved payments before choosing automatic cancellation. An expired card does not prove that an earlier capture failed. For installments, evaluate the individual unpaid and due slice, not only the parent period. ## Before replying to the customer Always check four things: payment provider, invoice remainder, status of the specific payment, and any planned action. Do not say money was received based on an authorization date, a saved card, or a submitted Leverandørservice collection. When a refund is pending, give the displayed status rather than a guarantee about bank timing. A credit note can reduce an invoice without returning money. A chargeback or local reversal can change payment status without creating a credit note. Follow the invoice credit trail and payment refund separately when reconciling.