local_library Resource

Stripe Payment Solutions

Stripe is a Stanford-approved third-party e-commerce platform designed to securely accept payments online. Stripe provides a variety of payment products and methods (such as Visa, ApplePay, eCheck, etc.) and functions as an integrated solution for your payment collection needs. Stripe offers a wide range of simple-to-use features, and their platform reduces Payment Card Industry (PCI) scope while meeting compliance requirements. This page profiles Stripe payment solutions, payment methods, and costs, as well as the accounting and security practices merchants using Stripe will need to know.

Merchants have several Stripe-compatible payment solutions to choose from to meet their unique business requirements, transaction volume, and budget. Stripe supports the capture of additional fields of transaction-specific data (known as “metadata”) such as an invoice number or inventory SKU code. Metadata can be focused, individualized, and relevant to a particular merchant’s workflow. Stanford Merchant Services is available to consult with merchants to help select the best product fit for their unique use case(s).

Payment Flow

A traditional payment flow may require relationships with multiple vendors:

  • stand-alone front-end service provider
  • developer for department website redirection to secure payment pages
  • gateway
  • acquirer
  • processor

Stripe provides a vertically integrated solution that allows a merchant to collect payments without any additional vendor relationships, so choosing the appropriate front-end provider or creating a custom department website for the specific merchant use case is the only necessary step.

This diagram illustrates the payments flow for merchants using Stripe to accept payments. 

Summary of Front-end Solution Options

  Native Stripe Solutions Independent Software Vendor (ISV) Solutions Custom Solutions
Payment Solution Options Approved vendors list, includes Shopify, Slate, etc. Merchant’s application integrated with either Stripe Checkout or Stripe Elements
Costs See Costs section for details Can include subscription costs, a percentage of revenue, and other pricing models as per the vendor’s contract
  • Development costs vary by use case
  • No added Stripe costs to process via integrations, see Costs section for details
  • Fully outsourced, no code required
  • No additional vendor relationships to manage or fund
  • Flexible payment method selections
  • Fully outsourced, no code required
  • Unified front and back end is possible for specific use cases supported by an ISV’s solution
  • Business requirements may be fully met by leveraging custom metadata fields
  • A unified front end and back end is possible for all use cases via full customization
  • Minimal customization is possible
  • Hard to work with metadata
  • Limited customization is possible
  • Restricted to ISV's supported payment methods
  • Added costs and compliance obligations
  • Not fully outsourced, code required
  • Ongoing maintenance costs
Ideal Uses
  • Minimal business requirements
  • Limited available budget resources
Specific business requirements to be met, yet custom solution isn’t feasible
  • Complex business requirements
  • Substantial available technical and budget resources


Native Stripe Front-End Solutions

Stripe offers two native e-commerce products for merchants to choose from that do not rely on a third-party ISV or the development of a custom implementation.

  • Payment links are created within Stripe for defined payment flows
  • Merchant distributes the link by posting on a web, sending an email, etc.
  • Customers click on the link and remit payment via Stripe Checkout
  • Transaction records are available in the Stripe Dashboard
  • Invoices are created for specific customers within Stripe and emails are sent out by Stripe
  • Customers remit payment via Stripe Checkout
  • Transaction records are available in the Stripe Dashboard
  • Customers need not be defined in advance
  • Merchants are able to stand up an e-commerce payment flow in minutes
  • Links can be shared multiple times
  • Links can be shared by QR code to enable payment at point-of-sale
  • Stripe’s own ecommerce features can be leveraged: products, prices, inventory, coupons, etc.
  • Directly ties each payment to a specific customer
  • Native Stripe reports and exports will be immediately accessible
  • Only invoiced customers can remit payment
  • Odds of needing to process refunds is substantially reduced
  • Compatible with “pushed” forms of payment (ACH Credit)
  • Limited customization 
  • Unable to collect custom metadata
  • Tying payments to customer records outside of Stripe is fully manual
  • Incompatible with “pushed” forms of payment (ACH Credit)
  • High volume usage will incur added invoicing fees
  • Requires merchant to already have the customer’s information and desired transaction details ahead of time to input into invoicing system

Other Front-End Solutions

For questions about independent software vendors and custom solutions compatible with Stripe, please submit a support request for assistance.

While Stripe offers numerous payment methods, these are the most applicable to the Stanford merchant community.


Cards (V/MC/D/AmEx) and Wallets 
(Apple/Google Pay)

Bank Transfer
ACH Debit (pulled)

Bank Transfer
ACH Credit or Wire (pushed)

  • Customers input their card information at the merchant's front-end solution
  • Merchants receive instant authorization, confirmation, and payout
  • Customers input their bank information at the merchant’s front-end solutions
  • Merchants receive instant authorization, delayed confirmation (~5 business days) and payout
  • Customers initiate payment from their bank and send it to the merchant’s account with Stripe
  • Merchants receive delayed confirmation (1-2 business days for ACH, fewer for wires), and payout
  • Low friction
  • Fastest sale pipeline
  • Fastest certainty
  • Lower processing costs
  • Very low dispute risk
  • Flat fees (no percentage-based costs)
  • Supports international bank accounts
  • Near-zero dispute risk
  • Higher processing costs
  • Relatively high risk of disputes
  • Delay before confirmation
  • Higher friction for customer
  • Currently only works with U.S.-based accounts
  • Customer must act outside of your e-commerce flow
  • Not available in many front-end solutions
Ideal Uses
  • Low dollar value transactions
  • High slippage environments
  • Time-critical situations
  • High dollar value transactions
  • High elasticity of demand (increasing price to cover card fees risks loss of business)
  • High dollar value transactions
  • Business customers with existing infrastructure to send funds electronically

Stripe offers pay-as-you-go pricing, based on payments the merchant processes.

Fee Categories Payment Methods / Products Details Timing
Payment Processing fee* Cards (V/MC/D/AmEx) and Wallets (Apple/Google Pay)
  • 2.9% +30¢ per successful card charge
  • Additional 1% for international cards
  • $15 per chargeback, fully refundable if the dispute is resolved in merchant’s favor
Fees deducted from transaction amount in real time; merchant receives net payout
Bank Transfer - ACH Debit (pulled) 0.8% capped at $5 per ACH debit transfer  
Bank Transfer - ACH Credit or Wire (pushed)
  • $1 per ACH credit transfer
  • $8 per wire transfer
Point of Sale Coming soon!  
Stripe Solution fee Invoices 0.4% per paid invoice Fees deducted from transaction amount in real time; merchant receives net payout
Payment Links None
Terminal Coming soon!
Merchant Services fee   0.8% of net Stripe revenue charged via iJournal Monthly iJournal to department PTA by MS

*Note: If a third-party software vendor is used to integrate with Stripe, pricing and fees may vary as per the vendor’s contractual terms.

A manually entered card payment is a transaction in which a customer’s card details, such as credit card number, have been entered into Stripe by merchant staff via the Stripe Dashboard using a web browser on non-PCI designated devices. This includes:

  • One-time payments where the customer’s card details have been typed into the Stripe Dashboard at the time of transaction
  • One-time payments using a saved card on file whose details were previously typed into the Stripe Dashboard
  • The first subscription payment using a card whose details have been typed into the Stripe Dashboard

Merchants who collect customer card details and then directly type in the  sensitive credit card information through Stripe’s online dashboard are using unencrypted channels that are not PCI compliant. It can lead to fines, increased fraudulent activities, and higher processing costs. Examples of unencrypted sources to avoid include text messages, emails, softphones (Jabber), regular work or personal computers, tablets, smartphones, etc.  Instead, Merchant Services recommends utilizing one of the secure, easy-to-use Stripe Payment Link or Stripe Invoice options if possible.

If these options do not suffice for your business requirements, please submit a support request for consulting services.

Stripe remits payment to Stanford net of fees.  To account for both revenue and fees accurately on the Oracle Financials General Ledger (G/L), the gross revenue must be recorded and the expense for fees paid must be entered into the G/L separately.

Example: Note that the assumed fees used in calculations below are simplified for demonstration purposes and do not reflect the actual Stripe processing fees structure a merchant will encounter.

  • Your customer pays $100 for your product/service on your e-commerce website.
  • You receive $97 of the sales price deposited in your PTA because Stripe automatically deducted a $3 processing fee during transaction processing.
  • You then need to record the full earned revenue as $100 (not $97) by creating a journal entry to record the $3 processing fee as an expense and increase the revenue to the full sale amount:
    • Credit $3 to your PTA revenue account (i.e. Project-Task-Award-46630)
    • Debit $3 to your PTA expense account (i.e. Project-Task-Award-54350)

By following this example the revenue is stated correctly, and Stanford’s financial records and statements will be accurate. 

As a reminder: 

  • All revenue from Stripe must flow into a Stanford bank account and each department must provide this business information when applying for a Stripe account
  • Department cash flow G/L mapping in Oracle is required for merchant payment revenue to be accurately reflected on the university’s financial statements
  • The revenue from a Stripe account is posted to a single PTA (defined on the Stripe account application). If revenue received in a Stripe account is ultimately destined for more than one PTA, merchants must designate a single account to receive the funds and perform manual journal entries to allocate the funds to other PTAs. To help handle the reconciliation process, review possible strategies on the Stripe Reconciliation Tool guide.

Refunds are issued using the Stripe online dashboard and are processed immediately. Once issued, refunds cannot be canceled.

To process a refund:

  • Find the payment to be refunded in the payments overview page
  • Click the ••• to the right of the charge. From the resulting menu, select Refund Payment.
  • Enter either a full or partial refund. *Note that multiple partial refunds against a given payment may be issued, with the upper limit of total refunds issued being the amount of the initial payment
  • Select a reason for the refund from the options. If selecting Other, please provide an explanatory note that is attached to the refund.
  • Click Refund

Please note that there are no additional fees charged by Stripe to refund a payment, but the processing fees paid on the original payment will not be returned. 

For general information on refunds, see Issuing Refunds to Credit and Debit Cards.

Last Updated: Sep 19, 2022
Back to Top