← Back to all posts

Email Transaksional untuk Aplikasi Travel: Booking, E-Ticket, Pembatalan

Aplikasi travel punya siklus email yang lebih berat daripada ecommerce biasa. Satu pemesanan tiket pesawat bisa memicu 4-6 email berbeda dalam 24 jam, dan setiap email punya tingkat kebutuhan "harus sampai" yang berbeda. Email konfirmasi pembayaran yang terlambat 10 menit? Masih bisa ditolerir. E-ticket yang tidak pernah sampai? Penumpang datang ke bandara tanpa tiket — itu masalah layanan pelanggan yang mahal.

Artikel ini membedah arsitektur email transaksional untuk aplikasi travel, dengan contoh nyata dari pola yang dipakai platform seperti Tiket.com, Traveloka, dan startup hotel boutique di Indonesia.

Peta email dalam satu perjalanan

Siklus email per booking:

1. Booking pending — dikirim segera setelah user membuat pesanan, sebelum bayar. Berisi batas waktu pembayaran (biasanya 60 menit untuk airline). Ini email dengan urgensi tertinggi: kalau telat masuk, user kehilangan booking.
2. Konfirmasi pembayaran — trigger dari webhook payment gateway (QRIS/Xendit/Midtrans), bukan dari UI. Jangan pernah trigger dari "user klik tombol sudah bayar" — user bisa tidak klik.
3. E-ticket / voucher — PDF attachment atau link unduhan. Delay beberapa menit setelah payment confirm, karena issuer (airline/hotel) belum selalu langsung mengembalikan kode booking.
4. Pengingat keberangkatan / check-in — scheduled job H-1 dan H-3 jam. Ini email yang paling sering dilupakan developer travel saat desain, padahal justru ini yang mengurangi "lupa jadwal" complaint.
5. Pembatalan / refund — harus menyertakan estimasi waktu refund dan referensi transaksi. Email pembatalan tanpa angka refund = tiket masuk ke customer service.

Kenapa e-ticket sering gagal terkirim

Tiga penyebab paling umum di aplikasi travel Indonesia:

Attachment terlalu besar. PDF e-ticket berisi logo high-res dan font embedded bisa 2-4 MB. Beberapa provider email API membatasi attachment 10-25 MB total, tapi provider yang lebih ketat menolak di atas 1 MB. Solusi umum: kirim link unduhan saja, simpan PDF di object storage.

Kode booking yang "ngawur" di subject. Subject seperti E-Ticket 123456 tanpa nama maskapai dan rute lebih rentan dilaporkan sebagai spam oleh user yang lupa booking. Subject yang baik menyebut rute: E-Ticket CGK-DPS 26 Okt — KA271X.

Kirim dari domain yang belum diverifikasi. Domain pemesanan dan domain notifikasi harus sama. Kalau e-ticket dikirim dari [email protected] tapi landing page di namaapp.co, filter Gmail menganggap ini spoofing.

Pola kode: kirim e-ticket dengan attachment

Contoh minimal dengan MailAnvil — attachment base64, field attachments:

curl -X POST https://api.mailanvil.com/v1/send \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "[email protected]",
    "to": ["[email protected]"],
    "subject": "E-Ticket CGK-DPS 26 Okt — KA271X",
    "html": "<p>E-ticket Anda terlampir. Tunjukkan QR di attachment saat check-in.</p>",
    "attachments": [{
      "filename": "e-ticket-KA271X.pdf",
      "content": "JVBERi0xLjQK...",
      "content_type": "application/pdf"
    }]
  }'

Atau tanpa attachment — simpan PDF ke R2/S3 dan kirim link. Untuk e-ticket, link unduhan dengan expiry 7 hari lebih aman daripada attachment, karena user sering minta kirim ulang dan email kedua dengan attachment identik bisa memicu dedup di sisi klien.

Trigger dari webhook, bukan dari UI

Pola paling penting: setiap email dalam siklus travel harus punya satu trigger yang bisa dipercaya.

• Booking pending → trigger dari API booking sukses
• Payment confirm → trigger dari webhook payment gateway
• E-ticket → trigger dari callback issuer / polling job
• Reminder → cron job, bukan dari event
• Refund → trigger dari webhook refund gateway

Kalau Anda trigger payment-confirm dari UI, user yang menutup browser setelah QRIS terbayar tapi sebelum balik ke app tidak pernah dapat konfirmasi — dan itu 30-40% user QRIS di Indonesia.

Biaya: ini yang bikin startup travel Indonesia mikir dua kali

Volume email travel tinggi dan musiman. Startup travel kecil dengan 30.000 booking/bulan bisa kirim 100.000+ email/bulan. Bandingkan biaya:

• Resend Scale: $90/bulan untuk 100k email ≈ Rp 1,44 juta/bulan
• MailAnvil Max: Rp 749rb/bulan untuk 100k email

Selisihnya cukup untuk satu engineer makan siang sebulan penuh — atau, lebih relevan, cukup untuk menutup biaya infra monitoring. Untuk volume di bawah 3.000 email/bulan, MailAnvil gratis.

Checklist sebelum launch

• [ ] Semua 5 tipe email di atas sudah ada, bukan hanya booking confirm
• [ ] Domain pengirim terverifikasi DKIM (lihat dashboard → Domains)
• [ ] Webhook payment gateway → email confirm, bukan UI trigger
• [ ] E-ticket pakai link unduhan, bukan attachment >1 MB
• [ ] Reminder keberangkatan jalan dari cron, dengan timezone Asia/Jakarta
• [ ] Email pembatalan selalu menyertakan estimasi refund

Mulai gratis 3.000 email/bulan di mailanvil.com — API key aktif dalam hitungan menit, harga IDR dengan QRIS/GoPay.