> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wegive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Transaction Mapping

> Field-level mapping between WeGive transactions and Bloomerang transactions

# Transaction Mapping

WeGive **Transactions** map to Bloomerang **Transactions**. Only successful transactions ever push.

## Which transactions are sent

| Transaction status | Sent? |
| - | - |
| `success` | Yes |
| Anything else (`processing`, `failed`, `refunded`) | No |

## Push

```
POST transaction (or PUT transaction/{id} on update)
{
  "Date": <created_at, in org timezone, Y-m-d>,
  "AccountId": <owner.bloomerang_id>,
  "Amount": <amount / 100>,
  "Method": "CreditCard" | "Eft" | "None",
  "Note": "[wg-rt:<transaction.id>]",
  "Designations": [
    { "Amount": <amount / 100>, "type": "Donation", "FundId": <fund.bloomerang_id, or the configured default fund> }
  ]
}
```

Related records are pushed first if they don't yet have a `bloomerang_id`: the fund, then the owning donor. If the donor still has no `bloomerang_id` at push time, the push fails outright rather than sending a transaction with no owner.

<Note>
  Updates to an already-pushed transaction only happen when the transaction has a `correlation_id` (i.e. it's WeGive-originated) — a transaction WeGive pulled in from Bloomerang is never pushed back on a later change.
</Note>

## Payment method (`Method`)

| WeGive `source_type` | Bloomerang `Method` |
| - | - |
| `card` | `CreditCard` |
| `bank` | `Eft` |
| anything else | `None` |

There's no separate mapping for check, cash, Venmo, PayPal, crypto, or stock — all of those fall into `None`.

## Fund designation

Every transaction sends **exactly one** `Designations` entry — split/multi-fund gifts aren't supported by this integration. If the transaction's fund has no `bloomerang_id` yet, the integration's configured Default Fund ID is used instead.

## Amounts

WeGive stores amounts in cents; Bloomerang in dollars. Amounts are divided by 100 on push (and multiplied by 100 on pull). There's no separate `Fee`/`CurrencyCode`/`CreditNote` field in the payload.

## Round-trip marker

Every pushed transaction's `Note` carries a machine-readable marker (`[wg-rt:<id>]`) that lets a later pull recognize this transaction came from WeGive instead of creating a duplicate — see [Integration Nuances](/external/onboarding/bloomerang/integration-nuances) for how this works.

## Pull (Bloomerang → WeGive)

Transactions are pulled via `GET transactions` (50 per page, filtered by `lastModified`), queried once per Bloomerang transaction type (`Donation`, `PledgePayment`, `RecurringDonationPayment`) and imported as Transactions:

| WeGive field | Source | Notes |
| - | - | - |
| `bloomerang_id` | Transaction `Id` | |
| `bloomerang_number` | `TransactionNumber` | |
| `amount` | `Amount * 100` | Only set when the transaction doesn't already have a `correlation_id` |
| `description` | `Description`, else `"Bloomerang Import"` | |
| `created_at` | `Date` | Stored at 17:00:00 in the org's timezone |
| `status` | `IsRefunded === 'No'` → success, else refunded | |

**Matching**: a pulled transaction is matched first by `bloomerang_id`, then by the round-trip `Note` marker (or the legacy `WeGive ID: <id>` text) if no direct match exists; otherwise a new transaction is created.

**Owner resolution**: matched by the transaction's `AccountId` against a donor's `bloomerang_id`.

**Source-of-truth guard**: a transaction with a `correlation_id` is never overwritten by a pull — amount, date, and description stay whatever WeGive originally set.

## Getting Help

* **WeGive Support**: [support@wegive.com](mailto:support@wegive.com)
* **Bloomerang API Documentation**: [bloomerang.co/features/api](https://bloomerang.co/features/api/)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.