IntegrityPhase B2B API Terms
Version 1.7.0_2026-10-14 | English
These Terms govern individual technical integrity checks bought by authorised agents for businesses established within supported EU VAT territories, including sole traders and business partnerships. These Terms, Privacy Notice and DPA form English package 1.7.0_2026-10-14. They apply prospectively only after the exact versions and hashes have been presented and expressly accepted within actual authority. Earlier contracts, acceptances and proofs are preserved. Preparing this package does not open sales.
1 Operator and eligible customers
The Operator is Marcin Podskarbi, trading as Marcin Podskarbi Prototype 1/2 Lab, a Polish sole trader, NIP 6222767998, REGON 545123210, Rolna 18A, 62-002 Suchy Las, Poland. General contact: contact@integrityphase.com. Support and complaints: support@integrityphase.com. Privacy: privacy@integrityphase.com. Billing: billing@integrityphase.com.
Customers must act for business purposes and have sufficient evidence of business status, identity and the applicable transaction tax treatment. Legal personality is not required. The standard scope covers the 27 EU Member States within the relevant EU VAT territory; special territories and unresolved establishments require a supported evidence-based decision before payment. Consumers are outside this offering; failed B2B qualification never creates a consumer offer. Natural persons acting as businesses retain any mandatory rights that apply to their transaction, including Polish Civil Code Article 3855 and the relevant Consumer Rights Act provisions for a directly business-related contract without professional character. An Agent's declaration does not waive those rights.
Customers and uses must be unregulated within these Terms. The onboarding declaration and objective checks establish eligibility for this service; the Operator does not provide a general legal assessment of a customer's business.
2 Service and definitions
The Service is the Operator's own technical API service, webhook_integrity.v1, invoked through POST /verify/webhook-integrity. One Operation is one admitted request resulting in one technical Proof. Free discovery, onboarding, document presentation, result access and invoice access are supporting functions, not additional paid products. MCP is an adapter to the same API and does not levy a second fee.
A Proof is the portable, signed record of the checks actually performed, including the required artifact, evidence package and receipt. A processing status alone is not a completed Proof. A Payload is the customer's submitted event data. An Agent is an identified technical API client acting within a Delegation. A Wallet is the payer address whose key is controlled by the signer. A Buyer Binding is the revocable link between the company, Delegation, Agent, Wallet, webhook source and permitted service scope; it is not itself proof of legal authority.
A Delegation is the signed package binding those parties and specifying allowed actions, spending limits, validity and revocation. Where the declared authority profile applies, its signer declares that the company authorised those actions. Signature verification proves control of the signing key and integrity of the package; it does not independently establish the signer's identity or legal right to represent the company. This declared model applies to the supported autonomous EU business path. Actual authority is still required to bind the company legally.
The reference value, event_value_eur, is a customer declaration used only for safety and admission. It must be EUR 100.00 to EUR 200.00 inclusive, with no more than two decimal places. It does not set the service price. The underlying transaction is identified by base_operation_id bound to buyer_id, source_id, Wallet, Delegation and event_id.
3 Checks and limitations of the Proof
The Service may check request format and schema, source authentication, timestamps, freshness, nonce and replay protection, configured technical policy, hashes and fingerprints. It assigns identifiers, records the necessary audit trail and returns the technical result. Only webhook_integrity.v1 is offered; historical method identifiers do not extend the offering.
A Proof does not establish the truth of source data, legal authority, validity of a contract or order, fulfilment of a payment, delivery, repair or other customer transaction, tax or accounting compliance, sector compliance or commercial value. Customers decide how to use the result and remain responsible for their systems and relationships with third parties.
IntegrityPhase does not provide audit, notarial, legal, financial, tax, medical, insurance or compliance advice. It is not a qualified trust service provider. To the extent a function constitutes an eIDAS trust service, it is offered only as a nonqualified service. No qualified signature, seal, timestamp, electronic delivery or electronic ledger is supplied. System time is technical metadata and carries no qualified presumption or guarantee of a legally certain date.
4 Onboarding and acceptance
An Agent may discover the service through the website, documentation, service catalogue or Bazaar and start onboarding through IntegrityPhase MCP or API. Catalogue metadata is an invitation to use the service, not evidence of activation or permission to pay. Presence in Bazaar and the availability of a particular payment provider are separate matters; no distinction between French, Polish and Czech Bazaar catalogues is asserted.
The Agent supplies the business name, establishment address and country, relevant VAT territory, tax identifier and VAT-UE number where available, the agreed invoice delivery method, and any different establishment receiving the service. It also supplies its identity, Wallet and existing signed Delegation. National company-register fields are not universally required. The server creates buyer_id after successful onboarding; it is not a prerequisite for a first customer. Onboarding accepts no business Payload. Company and invoice information goes to IntegrityPhase's API and necessary verification/accounting services, not to the blockchain or unnecessarily to payment providers.
Common qualification follows Articles 18–22 of Implementing Regulation 282/2011. Standard cross-border evidence includes VAT-UE validation and confirmation of the associated name and address. Positive, negative, insufficient-data and unavailable results remain distinct, with check dates and evidence. A valid number without sufficient identity evidence does not by itself complete this path. Absence of VAT-UE is not evidence that the customer has no business. Supported alternatives require independently checked domestic business evidence or a verified pending VAT application and reasonable identity checks; unresolved cases stop before payment. Place of supply takes account of the establishment receiving and using the service. National business registries may provide evidence without becoming a compulsory integration for every country.
The system records declared authority separately from independently checked business and tax evidence. It verifies the signed authority declaration, scope, validity, revocation and Wallet control; it does not independently certify the truth of the claim of representation. The Agent may accept documents only if its existing authority permits that action, including enter_dpa. Missing actual authority must be obtained from the principal outside IntegrityPhase; a model tool cannot create it.
The validate_and_present phase presents the full versioned Terms, Privacy Notice, framework DPA and offer only after the required checks. The accept_and_bind phase records explicit acceptance of the exact versions and hashes, using a fresh Wallet signature and valid presentation. The Agent must have the relevant delegated permissions, including enter_dpa. The framework DPA is accepted in every automatic onboarding, including where no personal data is expected. Acceptance does not authorise additional data categories.
The recorded acceptance identifies the company, Delegation, signed statement, signature and public key or fingerprint, Agent, Wallet, channel, time, document versions and hashes, check sources, dates and results, and Buyer Binding. A technical acceptance record does not conclusively bind a company through an unauthorised person. Ordering an Operation requires acceptance of its concrete offer within actual and declared authority.
Missing, false, inconsistent, expired or revoked evidence, excess limits, outdated documents, invalid VAT or an unqualified company cause automatic refusal before payment. Temporary registry unavailability results in a waiting response and bounded automatic retries. Failure to obtain confirmation blocks activation. There is no manual exception route or B2C fallback.
5 Delegation and technical requirements
The Agent may select the provider, accept documents, order and pay only within its Delegation. Customers must keep company and billing data current, protect keys and source secrets, maintain secure HTTPS integrations and follow the published formats, limits, timeouts and recovery instructions. Private keys and seed phrases must never be provided to IntegrityPhase.
Delegation revocation uses the documented issuer signed API request. It permanently disables the affected declaration and further access under that declaration, including protected result access; it does not undo a confirmed payment. Renewal requires a new delegation identifier and revalidation. Loss or suspected compromise of a key must be reported promptly. Incident handling is not manual approval of normal purchases.
The Operator may suspend credentials for security, revocation, exceeded limits or a legal obligation. The dashboard is private and is not a customer portal. Its existence does not grant an Agent access or authority.
6 Price and USDC settlement
The service price is EUR 20.00 net plus the VAT applicable to the qualified transaction. Where the service is taxable in Poland at the standard rate, VAT is EUR 4.60 and the amount due EUR 24.60. A qualifying cross-border B2B service follows reverse charge at the place of supply: EUR 20.00 due to the Operator, with the invoice annotation reverse charge. Reverse charge is not a Polish VAT zero rate. Neither the country prefix alone nor a payment provider determines the tax profile. There is no subscription or automatic B2C fallback.
For this release payment is the USDC equivalent of the EUR amount due, using native Circle USDC on Base, network eip155:8453, contract 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913, six decimals. The quote uses the approved Kraken USDC/EUR policy: divide the gross EUR amount by the quoted EUR per USDC rate, then round upwards to the nearest 0.000001 USDC. IntegrityPhase fixes the USDC/EUR rate once per calendar day in the Europe/Warsaw time zone, using the first successfully stored market observation obtained that day; that observation must be less than five minutes old at fixing. The resulting USDC amount for each applicable gross EUR price stays unchanged until 24:00 at the end of that same local calendar day, including after a service restart. The next calendar day requires a new fixing. The rate source, observation time, fixing time and exact expiry are recorded with the quote. The Operator bears subsequent intraday changes in the USDC/EUR rate for this fixed service price. Price validity does not extend sales availability, customer qualification, spending limits or a payment authorisation. There is no assumed EURC to USDC or USDC to EUR parity.
The order specific offer states the EUR net, VAT and gross amounts, USDC amount and atomic amount, rate source and time, expiry, network and contract, payer, approved pay_to, facilitator, payment identifier and policy versions. An expired offer must not be paid. A replay of the same order retains the originally bound quote; the system does not silently reprice an already started payment.
The reference value is not money accepted, held or transferred by the Operator for the customer or a third party. Missing base_operation_id, repeated use, conflicting bindings or reuse of the same source fingerprint under another event ID are rejected. Splitting operations to evade limits is prohibited. The system does not claim to detect every deliberately false semantic identifier.
The Agent signs the x402 payment with its own Wallet. IntegrityPhase API is the sole settlement owner. Eligibility and authority checks precede settlement. Only a settlement matching payer, pay_to, network, token, exact atomic amount and order authorises release. A proxy that settles before the product performs those checks is not a supported purchase path. Bazaar discovery may direct the Agent to IntegrityPhase MCP; discovery does not authorise proxy payment.
Historical EURC orders, receipts, invoices and accepted documents retain their original currency and terms. These Terms do not convert, replay or replace historical transactions. Network or Wallet fees, if any, are separately shown by the customer's payment provider; they do not change the quoted service price.
The Operator receives payment for its own API service. It does not operate a marketplace, customer account or balance, escrow, custody, exchange or payout service and does not execute customer payments to third parties. No CASP, VASP, investment, payment or AML or KYC service is supplied to the customer.
7 Completion and recovery
One accepted payment is linked to one Operation and one completed Proof. A status or pending identifier is not completion. Before payment, ineligible operations fail closed. A lost response or unknown settlement outcome is not permission to pay again. The Agent must query the original request through the authenticated status path; reconciliation uses the existing payment and Operation.
A confirmed settlement consumes the applicable limit even if later delivery fails. Failure of proof delivery, invoicing or KSeF never permits another settlement for that order. Service availability remains subject to the announced sales window and payment limits. These controls do not involve individual operator approval of routine customer purchases.
8 Invoices and delivery
The invoice is denominated in EUR and identifies the verified company. After confirmed payment, completed Proof and reconciliation, the system creates one invoice binding, one invoice number and FA(3), and queues the invoice for KSeF. The daily dispatch window uses Europe/Warsaw. KSeF access, invoice acceptance, UPO archival and delivery to the customer are distinct facts and are recorded separately.
The agreed machine channel is authenticated API access, also available through MCP. After KSeF acceptance and UPO archival, the Agent retrieves structured invoice data and FA(3), together with the KSeF number, verification link and readable English HTML view. The verification link accompanies the structured invoice. A matching acknowledgement of the complete document hash creates the delivery receipt. Mere availability, a GET request or an email address is not recorded as confirmed delivery. The Agent must retrieve and acknowledge the invoice and retain its copy. Domestic KSeF receipt rules continue to apply.
Pending, rejected or uncertain KSeF status remains visible in the accounting workflow without repeating payment or creating another invoice. Recovery queries the original session and invoice. No unproved not_applicable status substitutes for required KSeF evidence. Refunds and corrections remain separately linked accounting operations and do not erase the original records.
TaxCoach sp. z o.o. provides the Operator's accounting services. The accounting data flows and recipients are described in the Privacy Notice. Owner funded diagnostic calls and transfers between the Operator's own accounts are not customer sales.
9 Data and prohibited uses
Customers submit only data needed for the check and provide a lawful basis, appropriate notices and documented instructions. Prefer identifiers, metadata and hashes over full personal data. Raw Payload is processed transiently and must not be retained in application configuration, admission records, databases, logs or backups. Persistent commitments contain the required identifiers and hashes, not the full Payload. The Privacy Notice and DPA govern the separate retention of technical and accounting evidence.
Before production processing the application checks current DPA acceptance and Delegation before reading the body and rechecks after receipt. Source signatures that depend on the body can only be verified after reading it; headers alone do not authenticate the source. Bytes can already reach network infrastructure, the operating system and the HTTP intermediary terminating TLS. This boundary is explained in the Privacy Notice and DPA.
Payloads must not include special category, medical, children's or criminal conviction data, unlawfully obtained data, passwords, private keys, seed phrases, raw API keys, payment signatures, malware or unlawful content. Payment signatures belong only in the dedicated protocol field, transiently for settlement, not in the business Payload.
Prohibited uses include unlawful activity, infringement, fraud, phishing, unauthorised access, evasion of safeguards, sanctions or export controls, regulated financial, medical, employment or insurance decisions, safety critical decisions, or treating the Proof as legal confirmation of a transaction. Unauthorised security testing, reverse engineering or copying of the service is prohibited subject to mandatory law.
The offering excludes regulated entities, public administration, financial sector entities and entities subject to special NIS2 or DORA requirements. Any future service for them requires a separate agreement outside this onboarding process, not an individual exception.
10 Availability and continuity
The Operator may limit request volume, Payload size, concurrency, endpoints, timeouts, retries and sales windows and perform planned or emergency maintenance. Planned changes are notified with reasonable advance notice where practicable. Security, compliance, failure or fail closed controls may require immediate suspension.
No continuous availability, particular response time, RPO or RTO is guaranteed without a separate SLA. Before production the Operator maintains proportionate risk, onboarding, incident, termination, backup, integrity checking, restoration and reconciliation procedures. A significant incident follows the applicable eIDAS notification timetable, including the 24 hour route where required. Recovery establishes the last confirmed state and isolates uncertain operations before resuming.
11 Complaints and refunds
Send complaints to support@integrityphase.com with the buyer and available Operation or payment identifiers, time, problem and requested resolution, without Payloads or secrets. The Operator responds without undue delay, no later than the applicable statutory deadline; where a 14-day response duty applies it takes precedence over the ordinary B2B 30-day maximum. A statutory withdrawal or remedy does not depend on the Operator's discretionary approval or on technical accounting completion.
A refund or correction may apply where settlement succeeded but the Operator failed to complete its service or deliver the Proof, or where applicable mandatory law supplies a withdrawal, conformity or other remedy. Missing Proof or invoice does not prevent a complaint. Reconciliation uses existing payment identifiers and does not require a replacement purchase. Any contractual limits apply only where lawful. A buyer entitled to withdraw may send an unequivocal statement to support@integrityphase.com or the Operator's postal address identifying the contract and their decision; no special form is required. Where the statutory 14-day period applies it runs from conclusion of the service contract, subject to mandatory extensions. Immediate performance and any loss of withdrawal rights require the specific prior request, information and acknowledgement required by applicable law; acceptance of these Terms alone is not a blanket waiver. The prepared application presents a separate immediate-performance request and acknowledgement and records the authorised response with the exact document acceptance. That request covers each individual check ordered by that Agent within the stated authority; a new or changed scope requires renewed information and acknowledgement before payment. Loss of an applicable withdrawal right occurs only after full performance when all mandatory conditions have been met. Mandatory remedies, including conformity, complaints and protection against unfair terms, remain applicable. If the required conditions are missing, the purchase remains blocked before payment.
12 Responsibility and liability
Customers are responsible for their data, reference values, legal basis, systems, Delegations, Agents, Wallets, users, counterparties and decisions based on the Proof. Where a declared model applies, the Operator relies on the signed assertion of authority and does not eliminate company impersonation risk.
To the extent permitted by law, the Operator is liable only for actual direct loss caused by culpable failure to perform its own service, and aggregate liability for an Operation does not exceed its net fee. Lost profits, indirect loss, business interruption, customer system data loss and third party acts are excluded to the extent permitted by law. Internet, Base, cloud, Wallet or facilitator failures are excluded unless attributable to the Operator's fault. External attacks despite appropriate safeguards do not of themselves establish fault. Neither party is responsible for force majeure beyond reasonable control. Nothing excludes liability that mandatory law prohibits excluding or limiting.
13 Termination and intellectual property
Customers may terminate prospectively at any time by electronic notice. The Operator may terminate on 14 days' notice or suspend or terminate immediately for breach, API abuse, security risk, missing DPA, nonpayment, prohibited or regulated use, sanctions or legal requirements. Termination disables the Buyer Binding but preserves accrued payment duties and provisions concerning liability, data, complaints, claims and intellectual property.
The Operator and relevant licensors retain rights in the software, API, documentation, schemas, policies, names and know how. Customers receive a limited, nonexclusive, nontransferable, revocable right to use the API within the agreement and retain rights in their own data and systems.
Customers may retain, copy, use and share complete unaltered Proofs worldwide without a contractual time limit for independent verification and use as records of the checks performed. To the extent of the Operator's rights, the customer and such recipients receive a nonexclusive licence for those acts. Third party rights, confidentiality and data protection remain applicable. This does not transfer software or API rights or enlarge the meaning of the Proof. No trademark registration is asserted.
14 Sanctions and final provisions
Customers must comply with applicable Polish and EU sanctions and export controls and must not act for prohibited entities or evade restrictions. Automatic controls may deny access, and the Operator may suspend credentials for substantiated compliance or security risk. This is not approval of routine purchases.
English is the common contractual and machine-interface language for the supported EU business path. Polish law applies subject to mandatory protections and conflict-of-law rules. The agreed B2B venue at the Operator's seat applies only where lawful; it does not displace mandatory jurisdiction or statutory rights of a protected natural-person entrepreneur. A separate order or SLA prevails only on expressly specified matters. Invalidity of one provision does not invalidate the remainder.
Material changes are notified through the API, discovery or agreed electronic channel and require fresh acceptance when relevant before further paid use. Earlier versions and acceptance evidence are retained under their applicable retention rules. This version is prospective and does not rewrite historical EURC contracts. The Operator's income tax regime is not a customer qualification rule or an inference from the chosen payment token.
15 Agent applications and sales channels
A prepared application can use its existing EOA signer, standing budget and authority through the machine interface, without importing its private key into IntegrityPhase or completing an interactive IntegrityPhase configurator. Contract wallets are supported only after an identified implementation has been tested and explicitly documented. The hosting application enforces its granted budget; an Agent tool cannot raise it. Unresolved operations retain their budget reservations. Registered HMAC sources remain required; a Wallet alone does not authorise an arbitrary webhook.
The product qualification, source controls, proof, invoice and recovery records are shared across sales channels. A channel adapter supplies only its payment protocol. A channel such as Nevermined is unavailable until its seller eligibility, terms, currencies, networks and acceptance are specifically confirmed. A new channel does not create a second buyer onboarding or authorise a different payment. Standard x402 exact authorisation is not escrow or a reservation of funds: authorisation verification and settlement are separate operations.
Closing new purchases preserves existing operation, proof and invoice support while the required runtime remains available. Full runtime STOP also stops online aftercare and is reported separately. No scheduled reopening or continuous availability is promised.