Billing
Delivery workflow
Use the prepared package and an existing customer connection. This workflow runs against a local contract simulator; no real delivery or national acceptance is enabled.
What to do
- An organization owner declares the existing connection and customer mandate. Access references stay unverified; enter no passwords or tokens.
- Open the prepared export package, check the frozen recipient and connection, then prepare the delivery workflow.
- Check the recipient route locally. A submission remains blocked without matching route capabilities.
- After an unclear answer, reconcile the existing operation. A safe retry keeps the same reference and package.
- Fetch the matching receipt. Technical acceptance alone is not delivery. Keep the original response evidence.
Before you continue
Real sending, legal issuance and national acceptance remain disabled.
Access references remain unverified. Enter no passwords or tokens here.
The connection or company version changed. New submissions are blocked. An existing unclear outcome can still be reconciled.
The response could not be verified. No new delivery success is recorded.
Existing customer connection is declared once by the organization owner and stored as a version for the current company setup. Saved details are reused; reopening the page does not submit another declaration. Use the field help: the HTTPS address must contain no login, query or fragment; the customer account and agreement references are not passwords. The optional secure access reference accepts an existing UUID, not a token or private key. Saving metadata does not contact the provider, create access, verify a mandate or enable real sending. If a read fails, keep the form open and use Check saved connection details; saved data is not cleared and open inputs remain in this page. A changed company or connection version keeps the inputs and blocks saving until Review latest saved details is chosen deliberately. If a save response is unclear, check the stored declaration or confirm the same unchanged attempt; do not create a second declaration. A known rejection remains a rejection, never success. Closing or reloading loses unconfirmed inputs; confirmed declarations remain on the server. This mask supports the existing local contract workflow, not arbitrary provider APIs; missing generic protocol mapping is product work, while customer account, mandate and access references come from the customer.
Questions and troubleshooting
Can I start another submission after an unclear answer?
Reconcile the existing operation first. Do not create a second operation or switch its connection.
Can I change the connection before sending?
Discard a never-submitted preparation and prepare it again with the new declaration. Once a submission attempt exists, the original binding remains fixed.