Theme

Start for free

Integrations ยท Payment providers

Any other payment provider, through the Payments API.

Your server posts each payment it records to POST /api/v1/payments, with an API key that may record payments. Tally stores it and links it to the buyer's visit like a sale from a connected provider. DataFast's payment body works as is, so a switch keeps its code.

Start for free

14 days free, no card needed.

01What Tally records

  • A sale from any provider your server hears of, such as Gumroad, FastSpring, Dodo Payments, Creem, PayPal or your own billing, sent with its amount in the currency's main unit, the currency and a transaction_id.
  • Renewals: renewal set to true, with a subscription_id or customer_id, follows the subscription's first payment and keeps its source.
  • Refunds: refunded set to true takes back the payment its transaction_id names, by the amount sent; each partial refund takes a refund_id of its own.
  • Tax, when you send it, comes off the amount; what's left is converted to US cents at the European Central Bank's rate for the payment's day.
  • A transaction_id the site has already recorded is a duplicate, so a payment posted twice counts once.
  • A timestamp dates the payment, so one taken earlier counts on its own day.

02How a sale finds its visit

  • Visitor idSend the buyer's _tally_vid cookie as tally_visitor_id (datafast_visitor_id and visitor_id work too) and the payment links to that visitor. High confidence.
  • EmailSend email or customer_email and it's hashed at once, to match a tally('identify') call on your site. Medium confidence. A name is accepted and never stored.
  • Renewals and refundsA renewal takes the link of its subscription's first payment; a refund takes the link of the payment it reverses.

03What it can't read

  • Nothing is imported: only what your server posts arrives, so past payments count only if you post them.
  • In cookieless mode there's no visitor cookie for your server to read, so posted payments link by email only.
  • There's no chargeback field: the API records sales, renewals and refunds.
  • Free trials aren't revenue: a payment with an amount of 0, or is_free_trial, records nothing.
  • A payment a connected provider already reports shouldn't be posted too, or the same sale counts twice.

04Posting payments

  1. On your site's Setup page, make an API key and tick Record payments. A key without it only reads, and posting with it is refused with a 403.
  2. Where your server records a payment, post it to /api/v1/payments with the key as a Bearer token: amount, currency, transaction_id, and the buyer's visitor id or email.
  3. Read the visitor id from the _tally_vid cookie on the request that completes the purchase, or pass it from the page to your checkout.
  4. The answer says whether the payment was recorded or already had been; a body that isn't a payment gets a 400 with the sentence that says why.
  5. Posted payments show on the Integrations page as the Payments API, and each is linked to its visit within a few seconds.

A payment, posted with cURL

curl https://tallybyoutpost.com/api/v1/payments \
  -H "Authorization: Bearer $TALLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"amount": 29.99, "currency": "USD", "transaction_id": "order_1042",
       "tally_visitor_id": "the _tally_vid cookie", "email": "buyer@example.com"}'

05Questions

  • I'm switching from DataFast. Do I change my payment code?

    Only the address and the key. DataFast's path and body work as they are, amount, currency, transaction_id, datafast_visitor_id, email, renewal and refunded included, and its websiteId parameter is ignored, since the key names the site.

  • Which providers can I post from?

    Any payment your server records: Gumroad, FastSpring, Dodo Payments, Creem, PayPal, invoices your own billing marks paid. If your server learns of the payment, from a webhook or its own checkout, it can post it.

  • Can I send payments from before I started?

    Yes. Post each with its timestamp and it counts on its own day; a timestamp in the future is refused. Nothing arrives on its own, so the history is what you post.

  • What if my server posts the same payment twice?

    The second post is answered as a duplicate and nothing new is recorded, because transaction_id names the payment within the site. Retrying after a timeout is safe.