Transactions
- View as Markdown Open this page as plain Markdown (opens in a new tab)
- Open in ChatGPT Ask questions about this page (opens in a new tab)
- Open in Claude Ask questions about this page (opens in a new tab)
- Open in Google AI Studio Ask questions about this page (Google account required) (opens in a new tab)
Eventixa keeps transaction-related information with the associated booking so administrators can review how a payment was processed and reconcile it with the external payment provider.
Transaction information can help you investigate successful payments, failed payments, pending bookings, duplicate charges, refunds, and gateway mismatches.
Available in: Eventixa Core + Eventixa Pro
Location: Eventixa → Bookings → Open Booking
Related features: Payment Statuses, Bookings, PayPal, Stripe, WooCommerce, Offline Payment, Refunds
What Is a Transaction?
A transaction represents the financial payment activity associated with an Eventixa booking.
Depending on the payment method, a transaction can include:
- Payment gateway
- Amount
- Transaction ID
- Payment status
- Booking reference
- Payment timestamp or related booking timing
For offline payment, the transaction may be managed manually rather than through an automatic online gateway.
Where to View Transaction Information
Go to: Eventixa → Bookings
Open the applicable booking.
The Payment section can show information such as:
- Payment status
- Amount
- Gateway
- Transaction ID
Use this information to connect the Eventixa booking with the external payment provider.
Booking Reference vs Transaction ID
These are two different identifiers.
Booking Reference
Identifies the Eventixa registration.
For example: EC26001572
Transaction ID
Identifies the payment activity at the payment provider.
For example:
pi_...
A single support case may require both.
Why Both Identifiers Matter
The booking reference tells you which Eventixa booking to inspect.
The transaction ID tells you which financial transaction to inspect in the external provider.
Together, they help with reconciliation.
Transaction Amount
The transaction amount should match the final Eventixa payable total.
For example:
Ticket subtotal: $100
Coupon discount: $20
Final total: $80
The payment provider should record: $80 not $100.
Payment Gateway
The gateway identifies how the transaction was processed.
Examples include:
- PayPal
- Stripe
- WooCommerce
- Local / Offline
This helps determine where the actual financial record should be verified.
PayPal Transactions
For PayPal payments, the Eventixa booking can store the applicable PayPal transaction reference.
When troubleshooting, compare:
- Eventixa booking
- PayPal transaction
- Amount
- Payment result
Stripe Transactions
Requires Eventixa Pro
Stripe payments can include a payment reference such as a Payment Intent ID.
For example:
pi_...
Use this value to locate the corresponding Stripe transaction.
WooCommerce Transactions
When WooCommerce handles checkout, the commerce-side transaction can involve:
- WooCommerce Order ID
- WooCommerce order status
- Gateway transaction ID
Eventixa still maintains the event booking separately.
Offline Payment Transactions
Local / Offline payments do not necessarily have an automatically generated gateway transaction ID.
For bank transfer, cash, or manual payment, administrators may need to reconcile using:
- Eventixa booking reference
- Amount
- Payment date
- External bank/payment reference
Successful Transaction
A successful online payment should correspond to the expected paid Eventixa booking.
For example:
Booking status: Completed
Payment status: Paid
Gateway: Stripe
Amount: $80
Transaction ID: pi_...
Pending Transaction
A transaction can remain incomplete or pending.
This can happen when:
- Payment has not finished
- Gateway confirmation is delayed
- Offline payment is awaiting verification
- WooCommerce order is pending
Do not treat a pending transaction as paid.
Failed Transaction
A failed transaction means the payment did not successfully complete.
Possible causes include:
- Card decline
- PayPal cancellation
- Authentication failure
- Gateway configuration issue
- Payment provider rejection
A failed transaction should not be manually marked successful without external verification.
Refunded Transaction
A transaction can later be refunded.
The financial refund should be verified with the payment provider before Eventixa is updated to reflect the refunded state.
Transaction Reconciliation
Reconciliation means comparing Eventixa with the payment provider to make sure both systems agree.
For example, verify:
- Booking reference
- Transaction ID
- Amount
- Currency
- Payment status
- Timestamp
Why Reconciliation Matters
A booking can sometimes show a different state from the payment provider.
For example:
Eventixa: Pending
Gateway: Paid
or:
Eventixa: Paid
Gateway: Failed
These mismatches must be investigated carefully.
Customer Says They Paid
If a customer says they paid but Eventixa shows Pending or Failed:
- Find the Eventixa booking.
- Review the transaction ID.
- Open the gateway dashboard.
- Search for the transaction.
- Compare amount and time.
- Confirm the actual payment result.
- Reconcile Eventixa only after verification.
Customer Says They Were Charged Twice
Do not assume multiple booking attempts mean multiple charges.
Check the actual financial provider.
Compare:
- Transaction IDs
- Booking references
- Amounts
- Timestamps
If two successful transactions really occurred, determine which one belongs to the intended booking.
Duplicate Transaction Investigation
A useful process is:
- Search by purchaser email.
- Search by booking reference.
- Search by transaction ID.
- Compare timestamps.
- Compare amounts.
- Confirm which transactions succeeded.
- Refund any unintended duplicate through the payment provider.
Transaction and Booking Mismatch
If a payment belongs to the wrong booking, do not manually attach it to another booking without understanding the cause.
Eventixa uses booking/payment context to prevent incorrect transaction matching.
This is especially important with:
- Multiple browser tabs
- Repeated checkout attempts
- Waitlist reservation links
- Payment retries
Waitlist Transactions
Requires Eventixa Pro
A waitlist reservation can create a time-sensitive payment context.
When the customer pays, the transaction must match the correct protected booking.
Do not reuse a transaction from an unrelated booking.
Recurring Event Transactions
For recurring events, verify the booking belongs to the intended occurrence.
A transaction may be financially correct but still be associated with the wrong occurrence if the booking itself was incorrect.
Check:
- Event
- Occurrence
- Ticket
- Booking
- Transaction
Virtual Event Transactions
Virtual access should not be granted based only on the existence of a transaction.
The attendee should still have a valid Eventixa booking and eligible attendee status.
Transaction Currency
The payment provider currency should match the Eventixa booking currency.
If the amounts appear correct but currency differs, the transaction can still be wrong.
Always verify both:
- Amount
- Currency
Coupons and Transactions
Coupons change the final transaction amount.
For example:
Ticket total: $120
Coupon: -$30
Transaction: $90
The transaction should reflect the discounted payable total.
Quantity and Transactions
Multiple tickets increase the transaction amount based on quantity.
For example:
Ticket price: $19
Quantity: 3
Transaction amount:
$57
before applicable discounts.
Transaction Notes
Internal booking notes can help explain transaction-related activity.
For example:
Stripe payment verified manually. Transaction pi_… confirmed.
or:
Duplicate PayPal charge refunded.
Use notes for useful operational context.
Do Not Store Sensitive Payment Data
Never place sensitive card details in Eventixa notes.
Do not store:
- Full card number
- CVC
- Stripe Secret Key
- PayPal Secret
- Banking password
- Authentication tokens
A transaction ID is usually sufficient for reconciliation.
Transaction ID Privacy
Transaction IDs are useful administrative references but should still be treated carefully.
Avoid exposing real production transaction IDs in public documentation.
Blur them in screenshots.
PayPal Transaction Troubleshooting
If PayPal shows a successful payment but Eventixa does not:
- Verify booking reference.
- Compare transaction amount.
- Compare payment timestamp.
- Review Eventixa booking notes.
- Confirm the payment belongs to the same booking.
- Reconcile carefully.
Stripe Transaction Troubleshooting
If Stripe shows a successful Payment Intent but Eventixa is Pending:
- Open Eventixa booking.
- Copy the transaction ID.
- Find the Payment Intent in Stripe.
- Confirm status.
- Confirm amount.
- Confirm currency.
- Review Eventixa gateway synchronization.
WooCommerce Transaction Troubleshooting
For WooCommerce payments:
- Open Eventixa booking.
- Open the related WooCommerce order.
- Review order status.
- Review gateway transaction ID.
- Verify actual gateway payment.
- Compare the final order total with Eventixa.
Offline Payment Reconciliation
For Local payments, there may be no automatic online transaction.
Use:
- Booking reference
- Purchaser name
- Amount
- Payment date
- Bank or cash reference
to confirm the payment manually.
Transaction Time
Transaction timestamps can help identify:
- Duplicate attempts
- Late payments
- Payments after checkout expiration
- Refund timing
Always consider the site timezone and gateway timezone when comparing timestamps.
Payment After Checkout Expiration
If payment succeeds after Eventixa believes the checkout has expired:
- Do not ask the customer to pay again.
- Verify the gateway transaction.
- Check Eventixa booking timing.
- Review capacity.
- Reconcile the booking manually if needed.
Transaction and Capacity
The transaction itself does not directly define ticket capacity.
Capacity is managed by Eventixa booking and attendee state.
However, a successful transaction can lead to a confirmed booking that consumes capacity.
Failed Transactions and Capacity
A failed transaction should not permanently consume ticket capacity.
Verify the associated booking eventually releases the capacity according to Eventixa rules.
Refund Transactions
A refund creates a new financial event or changes the original transaction state depending on the payment provider.
Always verify:
- Original transaction
- Refund amount
- Refund status
- Refund timestamp
Partial Refunds
A partial refund does not necessarily mean the entire transaction is fully refunded.
For example:
Original transaction: $100
Partial refund: $25
Net paid: $75
Document this clearly.
Transaction History
The payment provider often provides more detailed transaction history than Eventixa.
For financial disputes, use the external gateway record as the authoritative financial source and use Eventixa for booking context.
Transaction Search
When investigating a payment, search using the most precise identifier available.
Recommended order:
- Transaction ID
- Booking reference
- WooCommerce order ID
- Purchaser email
- Amount and timestamp
Payment Provider as Financial Source of Truth
Eventixa tracks and synchronizes payment-related information, but the actual movement of money is recorded by the payment provider.
For financial questions, verify the gateway.
Eventixa as Booking Source of Truth
For event-registration questions, Eventixa is the relevant system for:
- Event
- Ticket
- Attendee
- Occurrence
- Capacity
- Booking
Use both systems together.
Transaction Audit Workflow
For any questionable transaction:
- Find Eventixa booking.
- Confirm event and ticket.
- Confirm booking amount.
- Check gateway.
- Copy transaction ID.
- Open payment provider.
- Verify amount and currency.
- Verify payment state.
- Compare timestamps.
- Review Eventixa notes.
- Resolve discrepancy.
- Add an internal note if needed.
Common Problems
Transaction ID Is Missing
Possible reasons can include:
- Payment has not completed
- Offline payment method
- Gateway has not synchronized yet
- WooCommerce transaction is stored with the order instead
Transaction ID Does Not Match Gateway
Do not manually replace it without understanding why.
Verify the booking and gateway transaction first.
Transaction Amount Is Wrong
Review:
- Ticket price
- Quantity
- Coupon
- Currency
- Final checkout total
Customer Has Two Transactions
Verify whether both are successful.
One may be a failed or abandoned attempt.
Customer Paid but No Booking Exists
Check the gateway transaction and any WooCommerce order.
Do not create a second payment request until the original transaction is understood.
Booking Exists but No Transaction Exists
Check:
- Free ticket
- RSVP
- Offline payment
- Failed checkout
- Pending payment
Not every booking requires an online transaction ID.
Transaction Is Paid but Booking Is Cancelled
The customer may still need a refund.
Review the refund workflow.
Transaction Was Refunded but Eventixa Still Shows Paid
Verify the refund and update Eventixa appropriately.
Recommended Transaction Review Workflow
- Go to Eventixa → Bookings.
- Open the booking.
- Review Payment Status.
- Review Gateway.
- Review Amount.
- Review Transaction ID.
- Review Booking Notes.
- Open the external payment provider.
- Search by transaction ID.
- Confirm amount and status.
- Reconcile any mismatch.
- Add a note where useful.
Important Notes
- Transactions connect Eventixa bookings with real payment activity.
- Booking references and transaction IDs are different identifiers.
- Always verify amount and currency.
- Do not treat Pending or Failed transactions as Paid without confirmation.
- Payment providers are the financial source of truth.
- Eventixa is the booking and registration source of truth.
- Offline payments may not have automatic transaction IDs.
- WooCommerce payments can involve an order ID and a gateway transaction ID.
- Coupons affect the final transaction amount.
- Never expose sensitive payment credentials or card information.
- Blur production transaction IDs in public documentation screenshots.
