For a variety of reasons, we would like to use Stripe to process payments in our proposed Tessitura web application. However, we know that hosted payment pages from Windcave are Tessitura's recommended solution (in the US). What potential ramifications would there be for the REST API implementation and the administration of Tessitura data if we chose to use Stripe to process transactions before ticket orders are saved to Tessitura?
Hi Cyrus,
Regarding REST API development, using a non-integrated payment provider like Stripe is supported and can be completed with standard functionality.
Regarding Tessitura administration, I'll call out a few initial considerations, and others might chime in based on experiences they've had. First, introducing another payment provider means that the organization's finance department will need to establish an account with them and be prepared to add the processor to their normal reconciliation process. Second, since Stripe cannot be used in the Tessitura client, the organization will need to continue processing application-based orders with one of our integrated partners. Third, any refunds to web orders will need to be processed in Tessitura (to release the tickets and ensure Tessitura's financial info is correct) as well as in Stripe (to actually get the money back to the customer).
As you get into your project, let us know how it goes!
Bouncing off this with two thoughts:
1. I wonder how difficult it would be to automate the process of refunding in Stripe, based on hooking into Tessitura via a service interceptor or even just watching the T_PAYMENT table periodically, and having this invoke some custom code to talk to Stripe's API when a refund is processed.
2. I think it was implied at a technical session last TLCC that there were future plans for the Tessitura services to integrate with payment providers such as Stripe and/or others in the same category... can you "neither confirm nor deny" that rumor for us, Michael?
We do not support and strongly do not encourage customization's to Tessitura's payment processing features (except reporting). Such customizations make it difficult to support the standard parts of the software, and the potential to cause harm in a critical part of the platform is too risky.
As for Stripe, we are still actively investigating Stripe as a potential integrated payment provider option, but no new news to share today.
Thanks!
Thanks for this information, Michael. It would be great if Stripe became an integrated ticketing partner in the future, as it has a big UX advantage in web applications versus the other gateways. I look forward to following the progress on that. I have a few follow-up questions:
1. When you say application-based orders will still need to be done with an integrated gateway, are you referring to orders by phone or other mediums? It doesn't seem very practical to use two different gateways for the same type of transaction, but maybe it wouldn't make much difference if the reporting is the same either way.
2. If you start a manual ticket order in the Tess admin, then go over to Stripe to charge the card, then copy that transaction ID back to Tess in the same PaymentReference field that would be populated by Stripe for a standard web order, would that work for the purposes of completing a manual order in a similar manner to a web session API checkout order? Are there other differences we need to consider between those two ordering flows?
3. Does the Tessitura admin have any type of webhook system where we could trigger something on our end in response to a refund processed on the Tessitura side? That would make connecting the Tessitura admin and Stripe possible in a limited capacity while we wait for it to be integrated natively.
Absolutely, happy to help!
1. Correct. Phone or walk-up orders would ideally need to be paid through an integrated payment provider. Most finance departments and auditors require the use of an integrated payment provider to eliminate the ability to charge a credit card for any amount at the operator's discretion, so the situations where non-integrated credit card processing is allowed are rare and tightly controlled.
2. The PaymentReference field is not editable from the front-end of the Tessitura application. If you complete a payment outside Tessitura and then manually record it back into the application, there is a notes field that you could put this into, but it is reference-only. And to your second question, there are a number of other fields and pieces of payment data that are not editable for an operator such as masked credit card number / last 4 digits or a payment provider authorization response code. Tessitura also handles declines and other kinds of two-way communication with the integrated payment provider that would not be recorded if you used something like Stripe.
3. No, we do not support and strongly do not encourage a web hook customization or another similar customization to Tessitura's payment processing features. Such customizations make it difficult to support the standard parts of the software, and the potential to cause harm in a critical part of the platform is too risky.
Overall we don't want to discourage the use of alternative payment providers on Tessitura websites. There are a number of them out there in use successfully. But credit card payment processing inside the application should remain with our approved integrated partners, and we recognize this means using two payment solutions simultaneously and all the responsibilities that comes with.
Thanks for the clarifications!