Bit2Me APIApple Pay and Google Pay
Wallet-pay funding via Teller proforma, execute, and Paylands checkout.
Your backend calls Bit2Me. Bit2Me returns a Paylands checkout URL after execute. You do not talk to Apple or Google SDKs for this rail.
Create the proforma
POST /v1/teller/order/proformamethod.type | Use |
|---|---|
creditcard | Card deposit |
google-pay | Google Pay |
apple-pay | Apple Pay |
hub-latam | LATAM rails |
Example body fragment: "method": { "type": "apple-pay" }.
Proforma 200 returns orderId and fee fields. It does not document waiting-user or provider.uri.
Execute
POST /v1/teller/order{ "orderId": "<proforma orderId>" }On HTTP 200 (ExecuteOrderData) you typically receive orderId, status (waiting-user when the user must pay), token, and provider.requestConfiguration.uri. Open that URI for the user.
HTTP 200 on execute means the checkout session was created. Payment finishes on Paylands.
UX rules (critical)
| Google Pay | Apple Pay | |
|---|---|---|
| API | "method": { "type": "google-pay" } | "method": { "type": "apple-pay" } |
| Open the URI | In-app WebView is OK | Do not use WebView or iframe |
| Apple constraint | — | Open in Safari / system browser |
The API may return "type": "iframe". Ignore that for Apple Pay. Apple blocks the Apple Pay button in iframes and WebViews.
Optional header if you control embed pages:
Permissions-Policy: payment=(self "https://api.paylands.com")This does not override Apple’s WebView rule.
Confirm completion
| Event | Meaning |
|---|---|
teller-order-v1 | Prefer this (orderId, status, type, error) |
teller.deposit.card.success | Legacy; prefer teller-order-v1 |
wallet-transaction-v1 | Wallet movement (may include tellerId) |
Optional poll: GET /v1/teller/order/status?id={orderId}.